Come scrivere “buon codice legacy”
Ecco alcuni punti di partenza per scrivere buon codice legacy. Il codice è molto più facile da scrivere che da leggere, e il modo migliore per risolvere i problemi è non crearli.
Scrivere meno codice
Meno codice = meno potenziale di bugs = meno da mantenere = meno “bad legacy”.
Scrivere meno codice potrebbe essere visto come il modo più importante per migliorare il codice in generale. Il principio DRY può essere visto come un corollario naturale e un mezzo primario per scrivere meno e ottenere di più.
Evitare // TODO e // FIXME
Scrivere // TODO o // FIXME dovrebbe essere visto come una bandiera rossa e un odore di codice.
Se traduciamo questi commenti nel loro significato reale allora “TODO” si traduce come “creare debito tecnico” e “FIXME” si traduce come “sto scrivendo intenzionalmente un bug”.
Ci possono essere rare eccezioni in cui rinviare una soluzione supera i benefici di risolverla ora, ma in generale, TODO e FIXME dovrebbero essere tenuti al minimo.
Preferite gli idiomi consolidati all’avanguardia
Questo potrebbe sembrare contraddittorio… usare tecnologie all’avanguardia rende il codice più “nuovo”, giusto? Beh, sì, ma crea anche il potenziale per andare fuori moda più rapidamente.
Dà anche ai nuovi programmatori un tempo più difficile per capire le cose. Se il codice è scritto usando idiomi e framework stabiliti, è probabilmente più facile da leggere e ha una migliore possibilità di funzionare più a lungo nel futuro.
Lascia sempre il codice in uno stato migliore di come l’hai trovato
Questo potrebbe sembrare che contraddica il “nessuna riscrittura” menzionato all’inizio, tuttavia, il miglioramento continuo e il refactoring è diverso dal fare una riscrittura significativa.
Prova a prendere l’abitudine di migliorare gradualmente e incrementalmente le cose. A volte un grande refactor o una riscrittura sono veramente necessari, ma il valore commerciale di questo deve essere attentamente soppesato rispetto ad altre priorità.
Continuate a migliorare come programmatore
Leggete libri, leggete post di blog, leggete il codice di altre persone, pensate attentamente al design e alle pratiche di programmazione. Riflettete consapevolmente sul vostro codice e pensate a modi per migliorare.
Piuttosto che incolpare il programmatore precedente per aver lasciato una cattiva eredità, assicuratevi di non diventare il programmatore che ne crea una nuova.
Siate sicuri che il vostro codice sia migliore.