Refactoring senza paura: tecniche per codice legacy
Ogni sviluppatore prima o poi si trova davanti a codice che nessuno vuole toccare. "Legacy" nel gergo tecnico non significa necessariamente vecchio: significa codice su cui non ci si fida di fare modifiche. Spesso è codice senza test, con dipendenze implicite e logica di business sepolta in funzioni lunghe 500 righe.
**Il primo passo: capire prima di cambiare**
Il refactoring senza comprensione è il modo più veloce per introdurre regressioni. Prima di toccare qualcosa, capite cosa fa quella funzione. Leggete i test esistenti (se ci sono). Tracciate le chiamate in ingresso e in uscita.
**La regola dei boy scout**
"Lascia il codice meglio di come l'hai trovato." Non cercate di riscrivere tutto in una sessione. Ogni volta che toccate un file per un bug fix o una feature, lasciatelo leggermente migliore: estraete una funzione, aggiungete un test, rinominate una variabile oscura.
**Characterization tests**
Prima di refactorizzare codice senza test, scrivete test che documentano il comportamento attuale, anche se quel comportamento è sbagliato. Questi test vi proteggono da regressioni durante il refactoring.
**Extract Method come punto di partenza**
Il refactoring più sicuro è estrarre parti di funzioni lunghe in funzioni più piccole con nomi significativi. Non cambia il comportamento ma rende il codice leggibile e testabile.
**Quando riscrivere da zero**
Quasi mai. La riscrittura completa è tentante ma pericolosa: il vecchio codice porta anni di bug fix impliciti che vengono persi nella riscrittura. The Joel on Software "Things You Should Never Do" rimane valido.
💬 Commenti (0)
Nessun commento ancora. Sii il primo!