Come vi ho detto ho appena letto questo libro e una delle cose più interessanti che vi ho trovato è la definizione di software legacy data usata dall'autore. Infatti secondo Feathers l'aspetto caratterizzante del codice legacy è l'assenza dei test di unità automatici.
A prima vista sembra questa affermazione non abbia senso. A noi sembra che il problema dei software legacy è semplicemente che sono progettati (e scritti) male.
Come sappiamo questo potrebbe non essere un gran problema se solo potessimo migliorare il design esistente, magari riscrivendo qualche porzione. Questo tipo di modifiche ha pure un nome, si chiama Refactoring e consiste nel cambiare la struttura interna di un programma mantenendone intatto il comportamento esterno.
Il refactoring comporta la modifica del codice esistente e quindi, come tutte le modifiche, se fatta in assenza del feedback di test automatici rischia di "rompere" il comportamento esistente.
Senza test è così facile introdurre bachi durante il refactoring che presto i programmatori e managers sviluppano una grande avversione alle modifiche del codice esistente.
Le conseguenze di questa "paura del refactoring" l'instaurarsi un circolo vizioso secondo il quale il nuovo codice non può essere scritto bene perché il codice esistente è scritto male. Quindi modifica dopo modifica il codice non migliora e, spesso, peggiora.
Questi sono i ragionamenti che portano a pensare che la caratteristica principale del codice legacy sia l'assenza di test di unità automatici.
A questo punto è facile capire quale sia la soluzione per interrompere il ciclo vizioso: è necessario mettere sotto test automatici le parti di applicazione che si intende modificare. Gran parte del libro è dedicata all'aggiunta dei test automatici al software legacy per abilitarne il refactoring e renderlo sempre di più un po' meno legacy.
