La maggior parte delle riscritture serve all'ingegnere, non al business
Per qualche settimana, un'estate, mi sono svegliato alle quattro del mattino per riscrivere codice che il mio datore di lavoro aveva già pagato qualcun altro per scrivere. Girava in produzione ogni giorno, ed era costruito su CakePHP. Conoscevo a malapena CakePHP, quindi ogni file mi sembrava sbagliato. Conoscevo Laravel, e adoravo lavorarci. Così, nel mio tempo libero, senza che nessuno me lo chiedesse, ho portato il tutto pezzo per pezzo, sostituendo i pacchetti Illuminate finché il vecchio framework non è scomparso.
L'abbiamo mergiata. Abbiamo iniziato anche il progetto successivo in Laravel. E non ho mai argomentato perché ne valesse la pena: non ne valeva, almeno non per il business. L'applicazione faceva lo stesso lavoro, per gli stessi utenti, alla stessa velocità di prima. La riscrittura ha migliorato esattamente una cosa: come mi faceva sentire il codice.
Questo è lo schema che vale la pena nominare. La maggior parte delle riscritture risponde all'ingegnere — a cosa vuole imparare, a cosa offende il suo gusto, a cosa fa bella figura in un colloquio — non all'azienda che paga lo stipendio.
Il codice funzionante è un registro di bug che qualcuno ha già risolto
L'argomento più forte contro una riscrittura non è lo sforzo. È la memoria. Il codice che gira in produzione da anni è un registro scritto di ogni bug che qualcuno ha incontrato e sistemato in silenzio. Il condizionale strano, il retry con il timeout sospetto: gran parte di quel codice è tessuto cicatriziale, e ogni cicatrice segna un incidente che non hai mai visto. Joel Spolsky lo ha scritto già nel 2000, definendo la riscrittura completa il singolo errore strategico peggiore che un'azienda di software possa commettere.
Butta via il codice e butti via anche le correzioni. Poi incontri di nuovo gli stessi bug, in produzione, davanti agli stessi utenti.
Ho lavorato su un sistema Perl che aveva già più di dieci anni, e su un CMS PHP costruito in casa più o meno della stessa età. Nessuno dei due somigliava a quello che scriverei oggi. Entrambi giravano e basta. Le aziende non ci hanno mai reinvestito, ed era la scelta giusta. Quel codice si era ripagato da tempo, e ogni anno tranquillo in cui continuava a servire traffico era puro guadagno.
Non familiare non vuol dire rotto
Ecco l'indizio che mi sono perso nella mia stessa storia. Ero convinto che il codice CakePHP fosse sbagliato, ma in realtà non avevo mai davvero imparato CakePHP. Non familiare non vuol dire rotto. Quando non conosci bene uno strumento, tutto quello che è costruito con esso ti sembra un errore, perché non riesci ancora a vedere le ragioni dietro le scelte. Quella sensazione di "è tutto sbagliato" è spesso solo il suono della tua incomprensione.
Parti dall'assunzione opposta: chi c'era prima di te non era stupido. Ha fatto scelte adatte al caso d'uso e ai vincoli che aveva in quel momento. Il codice ha la forma che ha per una ragione, anche quando quella ragione non è più visibile ai tuoi occhi.
Quando metterci mano è la scelta giusta
Niente di tutto questo significa congelare tutto. È la lettura pigra di "se funziona non toccarlo", ed è così che ti ritrovi a far girare nel 2026 un runtime a fine vita senza patch di sicurezza. Certo debito viene davvero a scadenza. Le condizioni oneste che ti costringono ad agire assomigliano a queste — non è una lista completa, solo quelle in cui mi imbatto più spesso:
- Il runtime o una dipendenza chiave è a fine vita, con CVE aperte e nessun percorso di aggiornamento.
- Una sola persona capisce il sistema, e si è appena licenziata.
- Ogni nuova funzionalità costa tre volte quanto dovrebbe a causa del design, e puoi dimostrare il trend.
- Il business ha bisogno di una capacità che il codice attuale non è mai stato pensato per sostenere.
L'ultimo punto è dove mi trovo proprio adesso. Sto riscrivendo un servizio, con un agente IA che fa gran parte della digitazione, perché ci serve che faccia qualcosa per cui non è mai stato costruito. Il codice funziona. Il business l'ha superato. È una ragione che ha un numero dietro.
Il test che separa una riscrittura vera da una di vanità è semplice: riesci a mettere una cifra sul dolore? Una CVE, una tassa sulla velocità, un'assunzione che non puoi fare, un lancio che mancherai. Se non salta fuori nessun numero, quello che hai è una preferenza di stile.
L'IA rende una riscrittura economica da scrivere e altrettanto difficile da fare bene
L'IA sposta questi conti, anche se non nel modo in cui sostiene la maggior parte delle persone. Il nuovo argomento è che le riscritture sono di nuovo economiche: il modello può portare un intero modulo in un pomeriggio, quindi perché non lasciarglielo fare. Ma scrivere il codice non è mai stata la parte costosa di una riscrittura. Lo era riscoprire il perché.
Un agente genera il sostituto in pochi minuti. Non sa perché il vecchio codice portava quel timeout strano: la ragione vive in un thread Slack del 2021 e in un postmortem che nessuno ha collegato al sorgente. Così produce qualcosa di pulito e plausibile, con il tessuto cicatriziale rimosso. Lo rilasci, e incontri di nuovo i vecchi bug, questa volta senza il contesto che il primo autore aveva quando li aveva risolti. Generare in fretta codice che ha dimenticato le proprie correzioni non è uno sconto.
Nemmeno la versione pulita resterà amata a lungo. Il motivo per cui il codice di oggi sembra un mucchio di errori altrui è che ha sopravvissuto al contatto con la realtà. Il sostituto scritto dall'IA si guadagna lo stesso destino. Tra due anni un ingegnere lo apre, non riesce a vedere perché ha quella forma, e sente lo stesso identico impulso di riscriverlo "come si deve".
Una generazione più economica non chiude quel ciclo. Lo rende più facile da avviare e più difficile da fermare. La via d'uscita non è un modello più lento. È scrivere le ragioni in un linguaggio semplice, così la prossima persona, o il prossimo modello, ottiene il perché, non solo il cosa.
Quindi, prima di riscrivere qualcosa che funziona, vai a cercare il numero. Se non ne trovi uno, quello che ha bisogno di manutenzione è la tua pazienza, non il codice.