Modernizzare un'applicazione legacy senza fermare il business
Riscrivere tutto da zero è quasi sempre la scelta sbagliata. Il metodo che uso per portare applicazioni cresciute male agli standard di oggi, un pezzo alla volta, mentre continuano a fatturare.
C'è una frase che sento in quasi ogni prima call: "il sistema funziona, ma nessuno vuole più metterci le mani". L'applicazione fattura, i clienti la usano, eppure ogni piccola modifica costa settimane, i bug spuntano in posti che nessuno aveva toccato e l'unico sviluppatore che "sa dove guardare" è diventato il collo di bottiglia dell'intera azienda.
La reazione istintiva — del management e spesso anche degli sviluppatori — è sempre la stessa: riscriviamo tutto da zero. Ed è quasi sempre la scelta sbagliata.
Perché la riscrittura totale fallisce
I numeri della grande riscrittura raramente tornano. Nel frattempo che il "sistema nuovo" prende forma, quello vecchio deve continuare a evolvere — perché il business non si ferma — e vi ritrovate a mantenere due sistemi con il budget di uno. La riscrittura insegue un bersaglio mobile: quando arriva alla parità di funzionalità, se ci arriva, il vecchio sistema nel frattempo ha accumulato due anni di nuove regole di business che nessuno ha documentato.
E c'è il rischio più sottovalutato: il codice legacy contiene conoscenza. Quel blocco if incomprensibile scritto nel 2019 probabilmente gestisce il caso limite di un cliente importante. Riscrivere da zero significa buttare via migliaia di piccole decisioni corrette insieme alle poche sbagliate.
I segnali che è ora di modernizzare (non di riscrivere)
- Il tempo tra "abbiamo deciso la modifica" e "è in produzione" cresce a ogni rilascio
- Il team ha paura di toccare intere aree del codice
- Le nuove assunzioni impiegano mesi a diventare produttive
- Gli aggiornamenti delle dipendenze sono fermi da anni ("non si può, si rompe tutto")
- L'esperienza utente è visibilmente di un'altra epoca, e i clienti iniziano a dirlo
Se vi riconoscete in tre o più di questi punti, la domanda giusta non è "riscrivere o tenere?", ma "in che ordine modernizzare?".
Il metodo: quattro fasi, nessun big bang
1. Audit onesto
Prima di decidere qualsiasi cosa, serve una fotografia: quali parti del sistema cambiano spesso (e quindi meritano investimento), quali sono stabili da anni (e possono aspettare), dove vivono i rischi veri. Il risultato non è un documento di cento pagine: è una lista prioritizzata di cosa toccare e — altrettanto importante — di cosa non toccare.
2. Il walking skeleton
Si costruisce lo scheletro della nuova architettura — build, deploy, test, monitoraggio, una pagina o un flusso end-to-end — e lo si porta in produzione subito, anche se fa una cosa sola. Questo smonta il rischio più grande di ogni modernizzazione: scoprire alla fine che l'infrastruttura nuova non regge la realtà.
3. Strangolamento incrementale
È il pattern che Martin Fowler chiama strangler fig: la nuova architettura cresce attorno alla vecchia, un flusso alla volta, partendo da dove il valore è più alto. Ogni pezzo migrato va in produzione e inizia a ripagarsi mentre il resto del sistema continua a funzionare com'era. Niente branch di due anni, niente "grande switch" dal quale non si torna indietro: ogni passo è piccolo, testato e reversibile.
4. Quality gate dal primo commit
La modernizzazione è anche l'occasione per installare le difese che impediranno al nuovo codice di invecchiare come il vecchio: test automatici in CI, controlli di tipo, lint, soglie di performance. Non alla fine — dal primo commit. Il codice nuovo che entra senza rete diventa il legacy di domani.
Gli errori che vedo più spesso
Modernizzare la tecnologia e non i confini. Passare da un framework vecchio a uno nuovo mantenendo lo stesso groviglio di responsabilità produce lo stesso groviglio, scritto con sintassi più moderna.
Fermare le feature durante la migrazione. Il business non aspetta, e un progetto di modernizzazione che blocca l'azienda perde sponsor in tre mesi. Il metodo incrementale esiste esattamente per questo: le feature nuove si costruiscono sulla parte nuova, mano a mano che cresce.
Misurare i progressi in righe di codice migrate. L'unica metrica che conta è quanto valore passa dalla parte nuova: percentuale di traffico, di transazioni, di flussi critici.
Quanto dura, realisticamente
Dipende dalla superficie, ma l'ordine di grandezza onesto per un'applicazione di media complessità è di mesi, non settimane — con la differenza fondamentale che i benefici arrivano in corsa, non alla fine. Il primo flusso modernizzato è tipicamente in produzione entro poche settimane dal kickoff, ed è lì che si vede se il metodo funziona: non su una slide, ma su traffico reale.
Ho guidato modernizzazioni in e-commerce, piattaforme enterprise e retail — è il lavoro che preferisco: prendere qualcosa che esiste e portarlo agli standard di oggi, senza fermare chi lo usa. Se la vostra applicazione mostra i segnali di cui sopra, parliamone: una call di 30 minuti costa zero e di solito chiarisce molto.