Cosa puoi fare per una base di codice legacy che avrà il maggiore impatto sul miglioramento della qualità?

Question

Mentre lavori in una base di codice legacy quale avrà il maggiore impatto nel tempo che migliorerà la qualità della base di codice?

• Rimuovi codice non utilizzato
• Rimuovi codice duplicato
• Aggiungi test unitari per migliorare la copertura dei test laddove la copertura è bassa
• Crea una formattazione coerente tra i file
• Aggiorna software di terze parti
• Riduci gli avvisi generati dagli strumenti di analisi statica (ad esempio Trova bug)

La base di codice è stata scritta da molti sviluppatori con diversi livelli di esperienza nel corso di molti anni, con molte aree non testate e alcune non verificabili senza spendere un tempo significativo nella scrittura di test.

Answer 1

• Leggi il libro di Michael Feather " Lavorare in modo efficace con il codice legacy "

Questo è un GRANDE libro.

Se non ti piace quella risposta, il miglior consiglio che posso dare sarebbe:

• Innanzitutto, smetti di creare un nuovo codice legacy [1]

[1]: codice legacy = codice senza unit test e quindi uno sconosciuto

La modifica del codice legacy senza una suite di test automatizzata in atto è pericolosa e irresponsabile. Senza una buona copertura dei test unitari, non è possibile sapere quale effetto avranno tali cambiamenti. Feathers consiglia un "stranglehold" approccio in cui si isolano le aree di codice che è necessario modificare, scrivere alcuni test di base per verificare i presupposti di base, apportare piccole modifiche supportate da test unitari e lavorare da lì.

NOTA: non sto dicendo che devi fermare tutto e passare settimane a scrivere test per tutto. Al contrario, prova solo le aree che devi testare e allenarti da lì.

Jimmy Bogard e Ray Houston hanno realizzato un interessante cast su un argomento molto simile a questo: http: // www .lostechies.com / blogs / jimmy_bogard / archive / 2008/05/06 / pablotv-eliminazione-static-dipendenze-screencast.aspx

Answer 2

Lavoro con un'applicazione LOC 1M legacy scritta e modificata da circa 50 programmatori.

* Remove unused code

Quasi inutile ... ignoralo. Non otterrai un grande ritorno sull'investimento (ROI) da quello.

* Remove duplicated code

In realtà, quando aggiusto qualcosa cerco sempre duplicati. Se ne trovassi qualcuno, inserisco una funzione generica o commento tutta la ricorrenza del codice per la duplicazione (a volte lo sforzo di inserire una funzione generica non ne vale la pena). L'idea principale è che odio fare la stessa azione più di una volta. Un altro motivo è perché c'è sempre qualcuno (potrei essere io) che dimentica di controllare altri eventi ...

* Add unit tests to improve test coverage where coverage is low

I test di unità automatizzati sono meravigliosi ... ma se si dispone di un arretrato eccessivo, l'attività stessa è difficile da promuovere se non si hanno problemi di stabilità. Vai con la parte su cui stai lavorando e spera che tra qualche anno avrai una copertura decente.

* Create consistent formatting across files

IMO la differenza nella formattazione fa parte dell'eredità. Ti dà un suggerimento su chi o quando è stato scritto il codice. Questo può darti qualche indizio su come comportarsi in quella parte del codice. Fare il lavoro di riformattazione, non è divertente e non dà alcun valore al tuo cliente.

* Update 3rd party software

Fallo solo se ci sono nuove funzionalità davvero interessanti o la versione che hai non è supportata dal nuovo sistema operativo.

* Reduce warnings generated by static analysis tools

Ne vale la pena. A volte un avviso può nascondere un potenziale bug.

Answer 3

Aggiungi test unitari per migliorare la copertura dei test. Avere una buona copertura del test ti permetterà di refactoring e migliorare la funzionalità senza paura.

C'è un buon libro su questo scritto dall'autore di CPPUnit, Lavorare efficacemente con il codice legacy .

L'aggiunta di test al codice legacy è sicuramente più impegnativa della creazione da zero. Il concetto più utile che ho tolto dal libro è la nozione di "cuciture", che Feathers definisce come

  

" un luogo in cui puoi modificare il comportamento del tuo programma senza modificarlo in quel luogo. "

A volte vale la pena eseguire il refactoring per creare cuciture che renderanno i test futuri più facili (o possibili in primo luogo.) Il google blog di test contiene diversi post interessanti sull'argomento, principalmente riguardanti il ??processo di Iniezione delle dipendenze .

Answer 4

Direi che 'rimuovi codice duplicato' praticamente significa che devi estrarre il codice e sottrarlo in modo che possa essere utilizzato in più punti - questo, in teoria, rende i bug più facili da correggere perché devi solo risolverne uno pezzo di codice, al contrario di molti pezzi di codice, per correggere un bug al suo interno.

Answer 5

Posso riferirmi a questa domanda dato che al momento ho in grembo una delle basi di codice della "vecchia" scuola. Non è un vero lascito, ma certamente non ha seguito la tendenza degli anni.

Ti dirò le cose che mi piacerebbe sistemare mentre mi infastidiscono ogni giorno:

• Documenta le variabili di input e output
• Rifattorizza i nomi delle variabili in modo che significino effettivamente qualcos'altro e un prefisso di notazione ungherese seguito da un acronimo di tre lettere con un significato oscuro. CammelCase è la strada da percorrere.
• Sono spaventato a morte per aver cambiato qualsiasi codice in quanto influenzerà centinaia di client che utilizzano il software e qualcuno noterà anche l'effetto collaterale più oscuro. Qualsiasi test di regressione ripetibile sarebbe una benedizione poiché ora ci sono zero.

Il resto è davvero noccioline. Questi sono i problemi principali con una base di codice legacy, consumano davvero un sacco di tempo.

Answer 6

Direi che dipende in gran parte da cosa vuoi fare con il codice legacy ...

Se rimarrà indefinitamente in modalità manutenzione e funzionerà bene, non fare nulla è la soluzione migliore. " Se non è rotto, non aggiustarlo. "

Se non funziona correttamente, la rimozione del codice inutilizzato e il refactoring del codice duplicato renderanno il debug molto più semplice. Tuttavia, vorrei apportare solo queste modifiche al codice errante.

Se prevedi la versione 2.0, aggiungi unit test e ripulisci il codice che porterai avanti

Answer 7

Buona documentazione. Come qualcuno che deve mantenere ed estendere il codice legacy, questo è il problema numero uno. È difficile, se non addirittura pericoloso, modificare il codice che non si capisce. Anche se sei abbastanza fortunato da ricevere un codice documentato, quanto sei sicuro che la documentazione sia corretta? Che copre tutta la conoscenza implicita dell'autore originale? Che parla a tutti i "trucchi" e casi limite?

Una buona documentazione è ciò che consente agli autori diversi dall'autore originale di comprendere, correggere ed estendere anche codici errati. Prenderò codice compromesso ma ben documentato che posso capire su un codice perfetto ma imperscrutabile in qualsiasi giorno della settimana.

Answer 8

L'unica cosa più grande che ho fatto per il codice legacy con cui devo lavorare è costruire attorno ad esso una vera API. È un'API COBOL in stile anni '70 in cui ho costruito un modello a oggetti .NET, in modo che tutto il codice non sicuro si trovi in ??un posto, tutta la traduzione tra i tipi di dati nativi dell'API e i tipi di dati .NET sia in un posto, il i metodi primari restituiscono e accettano DataSet e così via.

Questo è stato immensamente difficile da fare bene, e ci sono ancora alcuni difetti che conosco. Non è neanche terribilmente efficiente, con tutto il marshalling che continua. D'altra parte, posso costruire un DataGridView che trasferisce i dati di andata e ritorno a un'applicazione di 15 anni che persiste in Btrieve (!) In circa mezz'ora e funziona. Quando i clienti vengono da me con progetti, le mie stime sono espresse in giorni e settimane anziché in mesi e anni.

Answer 9

Parallelamente a quello che ha detto Josh Segall, direi che ne è stato un vero inferno. Ho lavorato su diversi sistemi legacy molto grandi che sono stati scaricati in grembo e ho scoperto che il problema più grande era tenere traccia di ciò che avevo già imparato su una particolare sezione di codice. Una volta che ho iniziato a inserire note mentre procedevo, incluso " To Do " note, ho smesso di ri-capire quello che ho già capito. Quindi potrei concentrarmi su come quei segmenti di codice scorrono e interagiscono.

Answer 10

Direi che lasciarlo solo per la maggior parte. Se non è rotto, non risolverlo. Se è rotto, vai avanti e correggi e migliora la parte del codice che è rotta e il suo codice immediatamente circostante. Puoi usare la sofferenza del bug o la funzione gravemente mancante per giustificare lo sforzo e le spese per migliorare quella parte.

Non consiglierei alcun tipo all'ingrosso di riscrittura, refactoring, riformattazione o messa a punto di test unitari che non siano guidati dalle reali esigenze aziendali o dell'utente finale.

Se hai l'opportunità di riparare qualcosa, allora fallo nel modo giusto (la possibilità di farlo nel modo giusto la prima volta potrebbe essere già passata, ma dal momento che tocchi di nuovo quella parte potrebbe anche farlo nel momento giusto) e questo include tutti gli elementi che hai citato.

Quindi, in sintesi, non ci sono singole o poche cose che dovresti fare. Dovresti fare tutto tranne che in piccole porzioni e in modo opportunistico.

Answer 11

In ritardo per la parte, ma può valere la pena fare ciò in cui una funzione / metodo viene utilizzata o referenziata spesso:

• Le variabili locali tendono spesso ad essere scarsamente nominate nel codice legacy (spesso a causa del loro ambito di espansione quando un metodo viene modificato e non vengono aggiornate per riflettere questo). Rinominare questi in linea con il loro scopo reale può aiutare a chiarire il codice legacy.
• Anche solo la disposizione del metodo in modo leggermente diverso può fare miracoli, ad esempio mettere tutte le clausole di un if su una riga.
• Potrebbero esserci già commenti di codice non aggiornati / confusi. Rimuovili se non sono necessari o modificali se assolutamente necessario. (Naturalmente, non sto sostenendo la rimozione di commenti utili, solo quelli che rappresentano un ostacolo.)

Questi potrebbero non avere il forte impatto che stai cercando, ma sono a basso rischio, in particolare se il codice non può essere testato in unità.