Riscrivere o riparare?

Question

Sono sicuro che siete stati tutti lì, avete intrapreso un progetto in cui c'è una vecchia base di codice scricchiolante che è a malapena adatta allo scopo e dovete prendere la decisione di riscriverla da zero o riparare ciò che già esiste.

La saggezza convenzionale tende a suggerire che non dovresti mai tentare una riscrittura da zero poiché il rischio di fallimento è molto alto.Allora cosa hai fatto di fronte a questo problema, come hai preso la decisione e come è andata a finire?

Answer 1

Dipende davvero da quanto è grave.

Se si tratta di un sistema piccolo e lo comprendi appieno, allora una riscrittura non è una follia.

D'altra parte, se si tratta di un gigantesco mostro legacy con dieci milioni di righe di codice misterioso non documentato, allora avrai davvero difficoltà con una riscrittura completa.

Punti da considerare:

• Se sembra buono per l'utente, non gli importerà che tipo di pasticcio di spaghetti è per te.D'altra parte, se fa male anche per loro, è più facile ottenere un accordo (e la pazienza).
• Se riscrivi, prova a farlo una parte alla volta.Una base di codice disordinata e disorganizzata può rendere difficile (cioè la sostituzione di una sola parte richiede una riscrittura di grandi iceberg di codice di dipendenza), ma se possibile, ciò rende molto più facile effettuare gradualmente la riscrittura e ottenere feedback lungo gli utenti lungo la strada .

Esiterei davvero a intraprendere un gigantesco progetto di riscrittura per un sistema di grandi dimensioni senza essere in grado di rilasciare la nuova edizione una parte alla volta.

Answer 2

Basta ripulire un po' il codice ogni volta che ci lavori.Se non ce n'è già uno, configura un framework di test unitario.Tutto il nuovo codice dovrebbe essere sottoposto a test scritti.Qualsiasi vecchio codice che risolvi a causa di bug, prova a inserire anche dei test.

Man mano che la pulizia procede, sarai in grado di spazzare sempre più codice dannoso in contenitori incapsulati.Quindi potrai eliminarli uno per uno in futuro.

Uno strumento come javadoc o doxygen, se non già in uso, può anche aiutare a migliorare la documentazione e la comprensibilità del codice.

Gli argomenti contro una riscrittura completa sono piuttosto forti.Quelle tonnellate di "piccoli bug" e comportamenti che sono stati codificati nel corso del tempo del progetto originale si insinueranno nuovamente.

Answer 3

Vedi il saggio di Joel Spolsky Cose che non dovresti mai fare.In sintesi, quando riscrivi perdi tutte le lezioni che hai imparato per far funzionare il tuo codice attuale nel modo in cui deve funzionare.

Guarda anche: Grande palla di fango

Answer 4

È raro che una riscrittura di qualcosa di complesso abbia successo.È allettante, ma è una strategia a bassa percentuale.

Ottieni il codice legacy tramite test unitari e rifattorizzalo e/o sostituiscine completamente piccole porzioni in modo incrementale quando opportuno.

Answer 5

Refactoring a meno che non sia davvero pessimo.

Joel ha molto da dire su questo...

Per lo meno, riscrivi il codice con il vecchio codice di fronte a te e non ricominciare da capo.Il vecchio codice può essere terribile, ma è così per una ragione e se lo ignori finirai per vedere gli stessi bug che probabilmente furono risolti anni fa nel vecchio codice.

Answer 6

Uno dei motivi per cui ho riscritto in uno dei miei lavori precedenti era l'incapacità di trovare sviluppatori con sufficiente esperienza per lavorare sulla base di codice originale.

È stata presa la decisione di ripulire prima la struttura del database sottostante, quindi di riscriverla in qualcosa che rendesse più facile trovare dipendenti e/o collaboratori a tempo pieno.

Non ho ancora sentito come è andata a finire :)

Penso che le persone abbiano la tendenza a riscrivere perché sembra più divertente in superficie.

Possiamo ricostruire da zero!

Lo faremo bene questa volta!

eccetera.

Answer 7

C'è un nuovo libro in uscita, Sviluppo di applicazioni brownfield in .NET di Baley e Belcham.Il primo capitolo è gratuito e parla di questi problemi da una prospettiva prevalentemente indipendente dalla piattaforma.

Answer 8

Riparare o, cosa più importante, eseguire il refactoring.Entrambi perché Lo ha detto Gioele e anche perché, se è il tuo codice, probabilmente hai imparato un sacco di cose in più dall'ultima volta che hai toccato questo codice.Se lo hai scritto in .NET 1.1, puoi aggiornarlo a 3.5 SP1.Puoi entrare ed eliminare tutto il vecchio codice commentato.Sei 100 volte migliore come sviluppatore ora rispetto a quando hai scritto questo codice per la prima volta.

Penso che l'unica eccezione sia quando il codice utilizza tecnologie davvero antiquate, nel qual caso potresti essere meglio servito scrivendo una nuova versione.Se stai guardando un'app VB6 con 10.000 righe di codice con un backend di database Access ovviamente configurato da qualcuno che non sapeva molto su come funzionano i database (che potresti benissimo essere tu otto anni fa) allora probabilmente puoi tirare una soluzione più rapida basata su C#/SQL in una frazione del tempo e del codice.

Answer 9

Non è così in bianco e nero...dipende davvero da molti fattori (il più importante è "cosa vuole che tu faccia la persona che ti paga")

Dove lavoro, abbiamo riscritto un framework di sviluppo e, d'altra parte, continuiamo a modificare alcuni vecchi sistemi che non possono essere migrati (a causa della tecnologia e dei limiti di tempo del cliente).In questo caso, proviamo a mantenere lo stile di codifica e talvolta è necessario implementare molte soluzioni alternative a causa del modo in cui è stato costruito

Answer 10

A seconda della tua situazione, tu Potrebbe hai un'altra opzione:codice di terze parti in licenza.

Ho consultato un paio di aziende in cui questa sarebbe la scelta sensata, anche se apparentemente "buttare via la proprietà intellettuale" può rappresentare un grosso ostacolo per la gestione.Nella mia azienda attuale, abbiamo preso seriamente in considerazione l'opzione praticabile di utilizzare codice di terze parti per sostituire il nostro framework principale, ma alla fine l'idea è stata rifiutata più per ragioni aziendali che per ragioni tecniche.

Per rispondere direttamente alla tua domanda, abbiamo finalmente scelto di riscrivere il framework legacy: una decisione che non abbiamo preso alla leggera!14 mesi dopo, non rimpiangiamo affatto questa scelta.Considerando solo il tempo impiegato per correggere i bug, il nostro nuovo framework si è quasi ripagato da solo.Il lato negativo è che non è ancora completo di funzionalità, quindi ci troviamo nella posizione poco invidiabile di mantenere due framework separati in parallelo finché non potremo eseguire il porting dell'ultima delle nostre applicazioni "front-end".

Answer 11

Consiglio vivamente di leggere "Lavorare in modo efficace con il codice legacy" di Michael Feathers.Si tratta di consigli di coaching su come rifattorizzare il codice in modo che sia testabile dall'unità.