Ogni organizzazione con sistemi critici arriva, prima o poi, a questa domanda.
E quasi sempre la pone nel modo sbagliato.
La domanda sbagliata è: “meglio riscrivere da zero o rattoppare quello che c’è?” Come se fosse una scelta ideologica. Una questione di principio.
Il vero costo non sta nella scelta tecnica. Sta nel tempo che un’organizzazione passa a rimandare quella decisione, mentre il sistema continua a funzionare “abbastanza bene da non toccarlo” e “abbastanza male da preoccupare tutti.”
Il downtime più costoso è quello delle decisioni rimandate. Non compare in nessun report di incident. Ma si paga lo stesso, ogni giorno.
Il mito da sfatare
Circola un’equazione semplice quanto sbagliata: rewrite uguale rischio, refactor uguale prudenza. Chi riscrive da zero viene visto come chi gioca d’azzardo. Chi rattoppa viene visto come chi gestisce con criterio.
In realtà esistono refactor molto più pericolosi di un rewrite ben pianificato.
Un refactor condotto senza criteri chiari, sistema dopo sistema, per anni, produce esattamente il rischio che dovrebbe evitare. Una stratificazione di correzioni che nessuno ricorda più perché sono state fatte. Che nessuno ha il coraggio di rimuovere. Che rende il sistema più fragile di prima. Non più leggibile. Non più sicuro. Solo più vecchio, con una patina di modernità applicata in superficie.
Un rewrite condotto con disciplina, con perimetro chiaro e piano di migrazione gestito, può essere la scelta più sicura che un’organizzazione compie in anni.
La sicurezza non è nella tecnica scelta. È nel metodo con cui viene applicata.
La causa reale
A decidere raramente è la tecnologia.
Più spesso decide la pressione del tempo. La paura di fermare un sistema che genera fatturato ogni giorno. L’assenza, dentro l’organizzazione, di qualcuno che conosca l’architettura esistente abbastanza a fondo da poter dire con onestà: “questo pezzo si può salvare, quest’altro va ripensato.”
Questa figura, quando manca, lascia un vuoto. Si riempie con l’opzione più rassicurante nel breve periodo: si rattoppa. Si aggiunge un altro livello. Si rimanda ancora.
Fino a quando il sistema smette di essere modificabile con criterio, e ogni intervento diventa una scommessa.
Nella pratica, la scelta corretta è quasi sempre mista. Un gestionale sviluppato dieci anni fa potrebbe richiedere il rewrite del motore di autenticazione, per adeguarsi agli standard di sicurezza moderni, mentre il modulo di fatturazione può restare invariato, isolato dietro un’interfaccia stabile, fino a una fase successiva. Un’applicazione monolitica da milioni di righe raramente viene sostituita in un’unica migrazione: viene separata in componenti autonomi, uno alla volta, mantenendo il servizio operativo per tutta la durata dell’intervento.
Le conseguenze
Il sistema “refactorizzato all’infinito” ha un tratto riconoscibile: nessuno, all’interno dell’organizzazione, riesce più a spiegare con precisione perché una certa parte del codice si comporta in un certo modo.
Il costo si vede su più fronti contemporaneamente:
- l’onboarding dei nuovi sviluppatori si allunga, perché non esiste più una logica coerente da spiegare
- il rilascio di nuove funzionalità rallenta, perché ogni modifica richiede prudenza estrema
- la dipendenza dalle poche persone che conoscono ancora il sistema cresce, invece di ridursi
- l’esposizione ai rischi di sicurezza aumenta, perché nessuno può più certificare con sicurezza cosa fa ogni componente
In settori regolamentati, questo non è solo un problema di efficienza. È un problema di continuità operativa e, spesso, di conformità. Un sistema che nessuno comprende fino in fondo è un sistema che nessuno può davvero certificare come sicuro.
La risposta di un’organizzazione matura
Le organizzazioni che gestiscono bene questo passaggio non scelgono a priori tra rewrite e refactor come fossero due scuole di pensiero.
Valutano, componente per componente, tre elementi concreti.
Quanto è critico quel componente per il funzionamento del sistema nel suo complesso, e quanto margine di errore è tollerabile durante l’intervento. Quanto profonda è la conoscenza residua, dentro l’azienda o presso il fornitore, di come quella parte specifica è stata costruita e perché. E quanta capacità ha il business di sostenere, per un periodo definito, un doppio binario: il sistema vecchio che continua a girare mentre il nuovo viene costruito e validato in parallelo.
Da questa valutazione emerge quasi sempre una risposta composita. Alcune parti si riscrivono. Altre si consolidano. Altre ancora si isolano dietro un’interfaccia stabile e si rimandano a una fase successiva.
Non è indecisione. È ingegneria applicata con metodo, non per principio.
Il legacy non è un problema da risolvere una volta per tutte. È una condizione con cui ogni sistema critico convive, per l’intera durata della sua vita utile.
Chi lo tratta come un’emergenza da chiudere in un progetto finisce per crearne un altro, identico, tra qualche anno. Chi lo tratta come parte ordinaria dell’architettura, da gestire con criteri chiari e continuità, costruisce sistemi che durano nel tempo.
Per questo, prima di parlare di rewrite o refactor, preferiamo partire da un’analisi architetturale: capire cosa genera valore, cosa rappresenta un rischio e cosa può continuare a funzionare. Solo dopo ha senso decidere quale strada seguire.