Ho recentemente finito di studiare Working Effectively with Legacy Code di Michael Feathers. 

Come immaginerete il libro parla di codice legacy. Noi abbiamo tutti un'idea di cosa sia il codice legacy. 
Tutti noi ne abbiamo avuto a che fare, a volte lo abbiamo creato e forse lo stiamo pure creando. Feathers nel suo libro utilizza una definizione tutta particolare ed interessante per definirlo ma in questo post vorrei invece ragionare sulla definizione di senso comune di codice legacy.

Secondo me, e penso secondo altri, il software legacy è qualcosa che possiede le seguenti caratteristiche:

• è utile:
• cioé serve alla azienda, crea valore.
• è difficile capirne il funzionamento:
• a volte ci sono delle incosistenze, 
• l'interfaccia d'uso non è lineare e contiene refusi ed errori storici 
• è fragile:
• ogni modifica può comportare un malfunzionamento, per esempio ti chiedono di modificare la formattazione dell'output e poi scopri che non salva più sul database!
• è difficile da modificare:
• a volte una "piccola" modifica ai requisiti richiede di rivedere grandi porzioni di programma, pensarci su, discutere e alla fine si riduce al cambiare una riga di codice in un certo punto magico
• a volte invece una "piccola" modifica ai requisiti richiede di fare delle modifiche in tanti diversi posti e devi ricordarti tutti i posti in cui lo devi modificare
• (a volte) è stato scritto da altre persone/enti:
• questo sarebbe il vero significato del termine legacy (cioè retaggio). Però nell'uso comune della parola in ambito software gli altri aspetti sono considerati più caratterizzanti. Infatti a volte si parla anche di software legacy riferendosi a software scritto da noi stessi (intesi come persona o azienda).

La caratteristica che ritengo più importante di questo tipo di software è la prima. Cioé

si tratta di un software utile e che crea utile!

Secondo me questo punto è veramente importante. 

Il fatto che il programma, anche se brutto, crei valore è il motivo per cui i nostri capi ci chiedono di lavorarci. 
E' il motivo per cui dobbiamo impegnarci per manutenere il programma e rendendolo migliore, o almeno ... non peggiore.

Però non è come dirlo. Non è facile. Ci vuole tecnica e impegno.

Riguardo all'impegno considero politiche del tipo "cerchiamo di toccarlo il meno possibile", "moltiplichiamo per 3.14 le stime prima di darle al management", "opponiamoci ad ogni richiesta di modifica" semplicemente non professionali.

Riguardo alla tecnica questa si è raccontata in questo libro e si acquisce studiandoloe applicandone gli insegnamenti.