Come superare l'anti-pattern & # 8220; Big Ball of Mud & # 8221 ;?

Question

Cosa causa la trasformazione di un programma per computer in Big Ball of Mud ? È possibile recuperare da questo anti-pattern? Esistono metodi di refactoring comprovati che possono essere applicati?

Answer 1

Di solito si verifica una grande palla di fango a causa di uno dei seguenti:

• Modifica dei requisiti s - Architetti una soluzione con una serie di requisiti, che nel tempo cambiano e ora probabilmente stai provvedendo a soddisfare un pubblico diverso che desidera utilizzare lo stesso prodotto con requisiti leggermente diversi. Inserisci tali requisiti nello stesso prodotto e finisci con una BBOM.

• Cambio di sviluppatori - Il prodotto originale è stato creato da un gruppo di sviluppatori con determinati presupposti di progettazione e architettura che non sono del tutto evidenti per un nuovo insieme di sviluppatori che "subentra 'il prodotto per mantenimento o ulteriore sviluppo. I nuovi sviluppatori fanno le loro ipotesi e nel tempo il prodotto si degrada in un mucchio di spazzatura non mantenibile.

• Incompetenza - degli sviluppatori (non sono consapevoli degli anti-schemi), della gestione (troppo impegnativa, della scarsa conoscenza del prodotto) o degli utenti (non lo fanno davvero sapere di cosa hanno bisogno). Questo è difficile da risolvere.

A volte, la soluzione migliore è semplicemente riscrivere l'applicazione soddisfacendo i nuovi requisiti. Ma questo è normalmente lo scenario peggiore. La soluzione ingombrante è quella di interrompere tutti i nuovi sviluppi, iniziare scrivendo una serie di test e quindi riprogettare e ri-ricercare l'intera soluzione. Tuttavia, ciò potrebbe richiedere anni, a seconda delle dimensioni del prodotto.

Answer 2

Le BBOM che ho incontrato sono state di solito create organicamente, in un processo darwiniano. Va qualcosa del genere:

1. Inizialmente, un sistema viene creato (non progettato) e scarsamente documentato.

2. Le risorse originali continuano a creare altro havok altrove, quindi non c'è nemmeno una storia orale per questo "retaggio". sistema.

3. Viene introdotto sangue fresco. Questi sviluppatori cercano di scoprire il funzionamento di varie parti del sistema, ma è come se molti ciechi cercassero di capire l'elefante quando uno ha afferrato la coda, uno una gamba e uno il tronco. Apportano cambiamenti ma non si sentono mai veramente sicuri di loro.

4. In questo modo, un sistema "si evolve" per selezione naturale cieca, ma parallelamente a questa è un'evoluzione dei bug più intrattabili e non riproducibili che persistono proprio perché rimangono sotto lo schermo radar, fino a quando ovviamente non emergono in un'installazione del cliente.

Answer 3

Ho sempre attribuito il termine (BBOM) a una base di codice in cui "tutto dipende da tutto" ed è difficile trovare il codice che vuoi cambiare, e quando fai una modifica finisci per cambiare roba dappertutto per farla funzionare di nuovo. È necessario l'intero codice di base per testare un singolo file / classe modificato. Lo zio Bob chiama questa sindrome del mattino dopo ( qui in base al principio delle dipendenze acicliche).

È praticamente inevitabile che una base di codice (ehm) devolverà in una BBOM in assenza del controllo di base delle dipendenze perché non può essere fatto dagli sviluppatori che non vedono altro che il codice stanno attualmente modificando.

Answer 4

Nel mio caso, un elemento del mio software che rientra in questo schema era una "soluzione temporanea", circa due anni fa, a cui sono state costantemente aggiunte nuove funzionalità (sempre con urgenza) a spese di una riscrittura.

Se non causa dolore gestionale, non hanno alcun incentivo a cambiarlo. " Sì, quando avrai tempo il prossimo mese, puoi riscriverlo, ma abbiamo solo bisogno che funzioni per questo caso proprio ora " ;. Non appena la nuova funzionalità è attiva, la riscrittura viene dimenticata.

Ho spiegato per due anni che è un povero codice (l'implicazione è che ci sono bug invisibili in esso).

Answer 5

L'unica volta che ho dovuto fare i conti con una "BBOM" scenario, in pratica abbiamo dovuto rivisitare i requisiti con gli utenti e dedurre ciò che potevamo dal codice orrendo. Come per tutte le BBOM, il problema di solito non si manifesta fino a quando non sono necessari alcuni interventi di manutenzione / miglioramento. (Nessun lusso di revisione del codice in questo negozio, i criteri erano purtroppo "fa quello che vogliono?") E "l'autore" è scomparso da tempo.

Il refactoring non è stato nemmeno possibile in questo caso.

Answer 6

La citazione pertinente dell'articolo di Wikipedia che risponde al tuo è:

  

Programmatori che controllano una grande palla   del progetto di fango sono fortemente incoraggiati   studiarlo e capire di cosa si tratta   compie e usarlo come a   base libera per un insieme formale di   requisiti per un ben progettato   sistema che potrebbe sostituirlo.

Answer 7

Questo potrebbe far luce sulla domanda originale.

http://en.wikipedia.org/wiki/Big_ball_of_mud

  

Una grande palla di fango è un sistema software privo di percepibile   architettura. Sebbene indesiderabile dal punto di vista ingegneristico,   tali sistemi sono in pratica comuni a causa delle pressioni aziendali e   fatturato degli sviluppatori. Sono stati quindi dichiarati design   anti-modello.