Come posso aggiornare una base di codice legacy di grandi dimensioni per soddisfare specifici standard di qualità?

Ci sono molte informazioni su strumenti e tecniche per migliorare le basi di codici legacy, ma non ho trovato casi di successo nel mondo reale. La maggior parte dei consigli è a livello micro e, sebbene utile, non convince molte persone a causa della mancanza di prove che può aiutare a livello macro.

Sto cercando specificamente miglioramenti incrementali che hanno dimostrato di essere un successo nel mondo reale quando si aggiorna una base di codice legacy di grandi dimensioni per soddisfare gli standard di qualità odierni e non una riscrittura completa.

Prima:

• Grande: maggiore di 1 MLOC
• Legacy: nessun test automatizzato
• Scarsa qualità: elevata complessità, elevato accoppiamento, difetti elevati sfuggiti

Dopo

• Test automatizzati
• Aggiornamenti / manutenzione più facili
• Alta qualità: complessità ridotta, codice disaccoppiato, pochi difetti sfuggiti

Che tipo di passaggi incrementali è stato dimostrato nel mondo reale di aggiornare con successo una base di codice legacy di grandi dimensioni per soddisfare gli standard di qualità sopra, senza passare attraverso una riscrittura totale?

Se possibile, includere una società di esempio o un caso di studio di un grande progetto legacy che ha superato un processo di miglioramento della qualità "riuscito" nella risposta per eseguire il backup.

Libri come http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 dovrebbero essere abbastanza testimoni di quanto le basi di codici di scarsa qualità legacy siano comuni nel settore.

La mia ipotesi sul motivo per cui non hai sentito o visto e, cosa più importante, probabilmente non ne avrai mai sentito parlare fino a quando non lavorerai su uno di loro da soli, è che nessuno sembra in grado per vari motivi di uscire pulito e dire che il loro codice la base era quanto sopra senza affrontare ripercussioni non banali.

Questo potrebbe spiegare la carenza di studi di cui parli. Se leggi abbastanza libri, ad esempio Deep C Secrets di Peter van der Linden, leggerai bug di milioni di dollari in cui mancherà la parte su quale progetto li ha persi.

NOTA: volevo rendere questo un commento, ma era troppo lungo. Capisco che questo non risponde completamente alla domanda.

EDIT: C ++ 11 & La fattibilità a lungo termine di GCC è messa in discussione - se gli sviluppatori rifattano GCC e lo rendono più utilizzabile come LLVM / clang, potrebbe fornire un buon esempio. La discussione rileva che la documentazione è scarsa in alcuni punti spingendo verso l'alto la barriera d'ingresso per i nuovi sviluppatori.

Il 3 febbraio 2013, Michael Meeks, uno degli sviluppatori di LibreOffice, terrà un discorso tra un paio di giorni dal titolo "LibreOffice: ripulire e ricoprire un gigantesco codice-base, o perché riscriverlo sarebbe ancora peggio ". Sembra esattamente quello che stai chiedendo: una discussione su ciò che hanno fatto per prendere "una base di codice gigantesca mal capita, ampiamente commentata in tedesco, senza unit test, un'infrastruttura di costruzione aggrovigliata e venticinque anni di debito tecnico non pagato "e modernizzarlo.

La presentazione può essere trasmessa in streaming online e (penso) le registrazioni saranno disponibili in futuro.

In realtà ho attraversato un refactoring abbastanza significativo tre volte nella mia carriera. Il codice tende a decadere, quindi se la tua base di codice è abbastanza lunga, un grande refactor è praticamente inevitabile. Tutti i miei esempi erano basati su codici privati, il che potrebbe spiegare perché gli esempi pubblici sono difficili da trovare.

La prima volta è stata un'applicazione che, che ci crediate o no, aveva un'architettura fondamentale che la faceva funzionare solo con le stampanti ad aghi. Quando la mia azienda non riuscì più a trovare un fornitore per fornire i nastri, mi assegnarono per farlo funzionare con una stampante laser.

La seconda volta è stata una migrazione di diverse centinaia di script di test automatizzati da C a Java, in parte perché avevamo bisogno di migliori capacità multipiattaforma e in parte perché stava diventando difficile assumere nuovi sviluppatori C.

La terza volta sono ancora nel mezzo, che sta modularizzando un'enorme applicazione monolitica per consentire i test delle unità riducendo l'accoppiamento e per scopi multipiattaforma.

Metto a confronto lo sforzo di scalare una montagna. Hai questo enorme obiettivo davanti a te, ma non lo affronti a livello macro. Lo prendi una maniglia alla volta, avendo sempre una posizione di fallback stretta, non scollegando mai la sicurezza precedente fino a quando la successiva non è a posto. Inizi solo apportando piccoli miglioramenti incrementali, e dopo un po 'ti giri e improvvisamente c'è questa bella vista.

Supponiamo che tu abbia 60.000 file di codice altamente accoppiato, per esempio. Vuoi iniziare a metterlo sotto test unitario, ma le dipendenze lo rendono impossibile. Come lo risolvi? Hai disaccoppiato un file. Aggiungi test automatici. Ritorni su un terreno stabile prima di proseguire. Ripeti 59.999 volte.

Se sembra semplice, è perché è semplice. Non è facile, ma è semplice. All'inizio è difficile notare dei progressi. Ci sono voluti due anni in quello che sembrava un refactor impossibile e probabilmente avremo anni prima di noi fino a quando non avremo finito, ma guardando indietro ci rendiamo improvvisamente conto di quanto il codice sia già migliorato e siamo stati in grado di continuare a offrire nuove funzionalità ai nostri clienti nel frattempo.

Le altre due volte hanno funzionato allo stesso modo. Trovi il più piccolo passo sicuro che puoi fare e lo fai, mantenendo l'applicazione sempre funzionante. Ti preoccupi solo del quadro generale per assicurarti di andare nella giusta direzione. Tutte le tue azioni sono piccole, costanti e incrementali.

Dall'esperienza personale di lavoro su una base di codice multimilionaria ho trovato alcune strategie che sembrano funzionare.

Guarda tutti i bug (anche quelli chiusi) e cerca di suddividerli in categorie. In particolare, provare a scomporli per il componente a cui appartengono. Se appartengono a più di un componente, nota che lo fanno. Una volta fatto questo sguardo a quale secchio è il più grande e usalo per determinare da dove iniziare. Inoltre, puoi consultare la cronologia delle revisioni dei file per determinare cosa cambia di più e utilizzarla come guida da dove iniziare. Fondamentalmente quello che stai cercando di fare è trovare ciò che è più rotto risolvilo e ripeti. Inoltre, ho scoperto che il tentativo di riparare tutto allo stesso tempo non funziona mai, ma causa solo più problemi.

Se trovi che ci sono molte cose che appartengono a più componenti che sono un'indicazione di problemi di "sistema" e possono indicare un codice troppo stretto o un'API che necessita di aggiornamento.

Un'altra area in cui ho trascorso molto tempo è testare la base di codice esistente. Ci sono più strategie qui e tutte hanno merito ma nessuno è una soluzione completa al problema.

• I test unitari possono funzionare ma spesso si è limitati a ciò che può essere testato a causa del codice strettamente accoppiato. Comunque fallo dove puoi.
• I test esterni sono un'altra strada. Presumo che probabilmente lo possiedi già e, in caso contrario, passerei un po 'di tempo a crearlo. Inoltre qualcosa che ha funzionato per me è aggiungere la possibilità di iniettare casualmente guasti / eventi nel sistema. Inoltre, prova a iniettare più cose contemporaneamente per cercare di far fallire in nuovi modi.