Come capire e debugare il software legacy? [duplicare]

Hai colpito il chiodo sulla testa: ciò di cui ti sei lamentato è la definizione di "software legacy". Lavorare su questa classe di software richiede una mentalità diversa per il lavoro sui campi verdi. Il tuo stress è il risultato del tuo misurare i tuoi progressi contro misure non realistiche.

Non cercare di mettere l'ideologia di oggi nel lavoro di ieri. Se non è stato progettato attorno a TDD e UT, allora la metodologia di prova guidata retro-fitting è un'impresa importante, costosa e difficile. Come stai scoprendo, oggi le pallottole d'argento non sono il modo ideale per lavorare. Se attentamente attraverso, con una chiara comprensione degli obiettivi e dei benefici, può valerne la pena. Tuttavia, si trasforma rapidamente in rendimenti negativi. Scegli il "frutto basso appeso" e sviluppa i test solo se è chiaro che saranno utilizzati molte volte e troveranno molti difetti.

L'approccio migliore è rimuovere aspettative non realistiche. La produttività sarà bassa, il codice difficile da analizzare e i difetti difficili da risolvere. È probabile che si verifichino effetti collaterali imprevisti dei cambiamenti e, come è stato accertato, il test di regressione è inesistente. Il mantenimento del codice legacy è lento e difficile, ecco perché così tanti sviluppatori si lanciano verso i progetti Green Fields. Posso essere gratificante, ma solo se resetti le tue aspettative.

Quando inizi a lavorare su un difetto, inizia concentrandoti su tre cose: cosa fa il codice ora, non introducendo effetti collaterali imprevisti e cosa dovrebbe fare quando viene risolto. Potresti scoprire che "la duplicazione del codice" è meglio di "effetti collaterali inattesi" ..... Senza test e requisiti decenti, introdurre la regressione è spesso il più grande peccato di tutti.

Cerca sempre di lasciare il codice in uno stato migliore di quello che hai trovato, ma fai attenzione a non cambiare il suo comportamento se non quando richiesto.

Questa è sempre una frequente area di dibattito per gruppi di utenti e conferenze che presento. Il miglior consiglio che abbia mai sentito è questo:

For new, well tested code, the tests are the source of all truth. For untested, legacy code, the codebase is the source of all truth. When adding a new feature, write solid unit tests. When addressing an existing module or fixing a defect, test as best you can, to avoid regression. Take your time, keep calm, and carry on.

Questa è chiaramente una parafrasi di alcune prospettive ben affinate, ma il nocciolo della questione è questo: il codebase è chiaramente "rotto", ma la funzionalità non lo è e questo è ciò che interessa agli utenti. Ma se diventa completamente non-sostenibile e hai un'idea su come reimplementare la funzionalità rapidamente e in modo sano, potrebbe essere il momento di far apparire la possibilità della temuta "grande riscrittura".

Ammetto che sono nel campo che dice che la grande riscrittura non è mai una buona idea, finché non lo è. Tu, il tuo team e i vostri clienti dovrete discutere e negoziare se o quando sarà giunto il momento. Buona fortuna, è una situazione terribile con nessuna soluzione corretta. Dovrei saperlo, ci sono già stato un paio di volte.

Questo è un lavoro lento. Essere pazientare. I tuoi colleghi sono probabilmente la migliore fonte di informazioni disponibili. Man mano che acquisisci conoscenza, aggiungi commenti in modo che il prossimo non debba reimparare ciò che già conosci.

Questo lavoro non è molto divertente e non fa molto per progredire nella carriera, quindi dovresti essere pagato di più di quello che otterresti per un nuovo sviluppo. Probabilmente non mi assumerei lavoro di questo tipo come dipendente stipendiato. Vorrei ottenere le tariffe dell'appaltatore compresi gli straordinari per le numerose "emergenze" che sicuramente sorgeranno.

Imparare a leggere e capire il codice di altre persone è una parte enorme dell'essere un programmatore. Alcuni dei codici che leggi saranno tuoi. Può essere pericoloso modificare il codice quando non si comprende appieno come si integri nel tutto. Introdurre i test unitari e farli funzionare come parte di un qualche tipo di sistema di build automatico ti aiuterà a mantenere il codice che coprono dal cambiare comportamento, ma questo significa (specialmente con il codice legacy) che devi capire come viene usato il codice che stai modificando dal sistema.

Può essere allettante gettare via il codice che sembra essere troppo complesso (o crufty, qualunque cosa significhi) e riscriverlo da solo. (Tutti vogliono essere l'architetto). Il pericolo nel buttare via il vecchio codice e riscriverlo da zero è che stai gettando via anche le conoscenze acquisite dal tempo e la dura esperienza che di solito sarà difficile da recuperare, tranne ripetendo gli stessi errori e correggendo gli stessi bug degli sviluppatori originali tempo.

L'introduzione del TDD in (o sopra) un sistema legacy può essere complicato. Preparati a correggere i bug in questi test poiché inevitabilmente troverai incongruenze nel codice stesso. Ricorda che i tuoi test non sono infallibili. Per capire meglio il sistema esistente, dovrai migliorarlo / correggerli.

C'è un approccio che ho trovato abbastanza utile mentre si lavora con situazioni simili a quelle che hai descritto. Di solito codice precedente scritto in modo molto monolitico e oscuro. Ma c'è un approccio interessante per iniziare a lavorare con il codice legacy: test di approvazione . Ti consiglierò di iniziare con la registrazione di copia d'oro e assicurarti che le informazioni acquisite contengano valori significativo per il tuo business. Il passaggio successivo mostra che copia dorata per l'analista aziendale. Di solito, sono in grado non solo di capire questa rappresentazione, ma anche di dirti cosa c'è di sbagliato in quei numeri, altrimenti a cosa servono gli analisti di business? Quindi, ora hai sia il risultato corrente dell'esecuzione del programma, commentato dall'analista, così da poter avviare in modo sicuro il refactoring e il bug fixing nel tuo codice legacy.