Ereditare qualcosa costruito da altri
Ogni sistema ereditato sembra peggiore di com’è, per lo stesso motivo per cui ogni città sconosciuta sembra pianificata male.
Prima o poi erediti qualcosa: una base di codice, un’automazione, un foglio di calcolo da cui dipendono tre reparti. Chi l’ha costruito è andato via o è occupato, la cosa funziona e nessuno sa dirti perché.
L’impulso a riscrivere sbaglia quasi sempre
Il lavoro altrui sembra brutto perché se ne vedono tutte le cicatrici e nessuna delle ragioni. Quella condizione strana in mezzo a una funzione non è sciatteria: è la correzione di un problema di un cliente del 2023 che nessuno ha annotato.
Riscrivere butta via quelle ragioni non documentate e le riscopre un incidente alla volta. Datti una regola: niente riscrittura prima di tre piccole modifiche riuscite. A quel punto o l’avrai capito abbastanza da riscriverlo bene, o avrai scoperto che va bene così.
Scopri cosa è portante
In ogni sistema ereditato una piccola parte fa quasi tutto il lavoro vero e una grande parte è decorazione: vecchi esperimenti, percorsi morti, funzioni che nessuno usa. Da dentro sembrano identiche.
Due modi economici per distinguerle. Guarda cosa cambia più spesso: il codice modificato di frequente è dove vive davvero l’attività. E guarda cosa viene eseguito più spesso. Tutto ciò che in un anno non è stato né modificato né eseguito è candidato all’eliminazione, ed eliminarlo è il modo più rapido per rendere comprensibile il resto.
Trova chi ricorda, prima di averne bisogno
Quasi sempre resta qualcuno che era nei paraggi quando è stato costruito, non necessariamente l’autore. Una persona del supporto che ricorda l’incidente, un collega che l’ha revisionato, il cliente che ha chiesto quel requisito strano.
Parlaci nella prima settimana, finché le tue domande sono ancora ingenue ed economiche, non al terzo mese quando sei bloccato e teso. Trenta minuti allora fanno risparmiare giorni dopo, e la memoria peggiora ogni mese che aspetti.
Fai una piccola modifica e rilasciala
Leggere codice sconosciuto insegna sorprendentemente poco; modificarlo insegna tutto. Scegli qualcosa di banalmente piccolo e portalo fino in produzione.
Imparerai ciò che ti serviva davvero sapere: come viene costruito, cosa si rompe quando lo tocchi, se i test significano qualcosa, chi se ne accorge. Quella è la mappa vera e non esiste in nessun documento. Scrivi cosa hai imparato in quella prima modifica: sei l’unica persona che vedrà questo sistema con occhi nuovi, e quello sguardo sparisce in un mese.
Domande frequenti
Devo riscrivere un sistema ereditato?
Non per prima cosa. Il lavoro altrui sembra brutto perché ne vedi le cicatrici e nessuna ragione; quella condizione strana di solito è una correzione non documentata. Fai tre piccole modifiche riuscite prima di pensarci.
Come capisco quali parti contano?
Guarda cosa cambia più spesso e cosa viene eseguito più spesso. Il codice modificato di frequente è dove vive l’attività; ciò che in un anno non è stato né modificato né eseguito è candidato all’eliminazione.
Cosa faccio nella prima settimana?
Trova chi era presente quando è stato costruito — non per forza l’autore — finché le domande sono ingenue, e porta una modifica banale fino in produzione. Poi scrivi cosa hai imparato.
