Quali sono i punti chiave per lavorare in modo efficace con il codice legacy? [chiuso]

Il problema chiave con il codice legacy è che non ha test. Quindi è necessario aggiungere alcuni (e poi altri ...).

Questo di per sé richiederebbe molto lavoro, come notato da @mattnz. Ma il problema speciale del codice legacy è che non è mai stato progettato per essere testabile . Quindi tipicamente si tratta di un enorme caos di codice spaghetti, in cui è molto difficile o addirittura impossibile isolare le parti piccole da sottoporre a test dell'unità. Quindi prima del test unitario, devi rifattorizzare il codice per renderlo più testabile.

Tuttavia, per effettuare il refactoring in modo sicuro, devi disporre di test unitari per verificare di non aver violato nulla con le tue modifiche ... Questa è la cattura 22 del codice legacy.

Il libro ti insegna come uscire da questa cattura apportando le modifiche minime e più sicure al codice solo per abilitare i primi test di unità. Questi non sono pensati per rendere il design più bello - solo per abilitare i test unitari. In effetti, a volte rendono il design più brutto o più complesso. Tuttavia, ti consentono di scrivere test e, una volta che hai eseguito test unitari, sei libero di migliorare il design.

Ci sono molti trucchi per rendere testabile il codice: alcuni sono ovvi, altri non lo sono affatto. Ci sono metodi che non avrei mai pensato a me stesso, senza leggere il libro. Ma ciò che è ancora più importante è che Feathers spiega che rende testabile un'unità di codice. È necessario tagliare le dipendenze e introdurre barriere nel codice, ma per due motivi distinti:

• rilevamento - per verificare e verificare gli effetti dell'esecuzione di un pezzo di codice e
• separation - per ottenere prima di tutto lo specifico pezzo di codice in un'imbracatura di prova.

Il taglio sicuro delle dipendenze può essere complicato. L'introduzione di interfacce, mock e Iniezione delle dipendenze è pulita e piacevole come obiettivo, ma non necessariamente sicura a questo punto. Quindi a volte dobbiamo ricorrere alla sottoclasse della classe sotto test per scavalcare un metodo che normalmente sarebbe, ad es. avviare una richiesta diretta a un DB. Altre volte, potremmo anche aver bisogno di sostituire una classe di dipendenza / jar con una falsa nell'ambiente di test ...

Per me, il concetto più importante introdotto da Feathers è cuciture . Una cucitura è un posto nel codice in cui è possibile modificare il comportamento del programma senza modificare il codice stesso . Costruire cuciture nel codice consente di separare la parte di codice sotto test, ma consente anche di rilevare il comportamento del codice in prova anche quando è difficile o impossibile fare direttamente (ad esempio perché la chiamata apporta modifiche in un altro oggetto o sottosistema, il cui stato non è possibile interrogare direttamente dal metodo di test).

Questa conoscenza ti permette di notare i semi della testabilità nel più brutto mucchio di codice e di trovare le modifiche minime, meno dirompenti e più sicure per arrivarci. In altre parole, per evitare di fare refattamenti "ovvi" che rischiano di infrangere il codice senza che tu te ne accorga, perché non hai ancora ancora i test dell'unità per rilevarlo.

Modi rapidi per ottenere i punti chiave di Lavorare efficacemente con il codice legacy

• Leggi Michael Feathers ' PDF di 12 pagine , scritto 2 anni prima del libro.
• Guarda la presentazione di Michael Feathers: 68 slide
• Ascolta un'intervista podcast con Michael Feathers. Per esempio. questo episodio di Hanselminutes di 30 minuti .

Lavoro su una base di codice di milioni di righe di codice, alcune risalenti agli anni '80. È solo un software, quindi è solo questione di scrivere alcuni test unitari, quindi puoi andare e solo rifattorici, e renderlo molto meglio.

La parola chiave qui è giusta - è una parola di quattro lettere che non appartiene al vocabolario di nessun programmatore, per non parlare di chi sta lavorando su sistemi legacy.

Quanto tempo ci vuole per scrivere un test unitario, per testare un'ora di impegno nello sviluppo? Per amor di discussione, diciamo un'altra ora.

Quanto tempo è stato investito in quel sistema legacy vecchio di venticinque milioni di anni? Diciamo, 20 sviluppatori per 20 anni di cui 2000 ore / anno (hanno lavorato abbastanza duramente). Ora prendiamo un numero - hai nuovi computer e nuovi strumenti, e sei molto più intelligente dei ragazzi che hanno scritto questo pezzo di $% ^^ in primo luogo - diciamo che ne vale 10. Hai 40 anni uomo, beh, hai ...?

Quindi la risposta alla tua domanda è che c'è molto di più. Ad esempio, quella routine che è 1000 righe (ne ho alcune che superano i 5000), è eccessivamente complessa ed è un pezzo di spaghetti. Basterebbe (ancora un'altra parola di quattro lettere) impiegare un paio di giorni per ridimensionarlo in poche poche routine di linea e qualche altro aiuto di 20 righe, giusto? SBAGLIATO. Nascosto in quelle 1000 righe ci sono 100 correzioni di bug, ognuna delle quali è un requisito utente non documentato o un caso limite oscuro. Sono 1000 righe perché la procedura originale a 100 linee non ha funzionato.

Devi lavorare con il set mentale " se non è rotto, non farlo correggilo ". Quando è rotto, devi stare molto attento quando lo aggiusti - come lo fai meglio, che non cambi accidentalmente qualcos'altro. Nota che "rotto" potrebbe includere codice che non è possibile mantenere, ma che funziona correttamente, che dipende dal sistema e dal suo utilizzo. Chiedi "cosa succede se rovino tutto questo e lo peggio", perché un giorno lo farai, e dovrai dire al capo dei capi perché hai scelto di farlo.

Questi sistemi possono sempre essere migliorati. Avrai un budget su cui lavorare, una tempistica, qualunque cosa. Se non lo fai - vai e creane uno. Smetti di migliorarlo quando il denaro / tempo è scaduto. Aggiungi una funzione, concediti del tempo per migliorare un po '. Risolvi un bug - di nuovo, dedica un po 'di tempo in più e rendilo migliore. Non consegnarlo mai peggio di quando hai iniziato.

Ci sono due punti chiave da togliere al libro.

1. Il codice legacy è qualsiasi codice che non ha copertura di prova.
2. Ogni volta che devi modificare il codice legacy, assicurati che abbia copertura.

Come hanno sottolineato altri rispondenti, il tentativo di aggiornare preventivamente il codice esistente esistente è un commissione di pazzi . Invece, ogni volta che devi apportare una modifica al codice legacy (per una nuova funzione o una correzione di bug), prenditi il tempo necessario per rimuovere lo stato precedente.

In un guscio di noce è vero - aggiungere test e refactoring è di cosa si tratta.

Ma il libro offre molte tecniche diverse per farlo con codice che è molto difficile da testare e refactare in modo sicuro.