Software legacy: quando conviene evolverlo e quando riscriverlo

Un software legacy, in molti casi, conviene evolverlo per gradi piuttosto che riscriverlo da zero in un colpo solo. La riscrittura completa ha senso solo in casi precisi: quando la tecnologia non permette più di intervenire in sicurezza, quando il software non rispecchia più il modo in cui lavori, o quando il costo di ogni modifica è diventato sproporzionato. Spesso la strada più prudente è un’altra: capire cosa c’è, mettere in sicurezza le parti critiche e sostituire pezzo per pezzo ciò che non regge più, senza fermare l’attività.

Cos’è davvero un software legacy

Legacy non significa solo vecchio. Un software è legacy quando l’azienda ne dipende per lavorare ma è diventato difficile da cambiare o da mantenere. Può essere in uso da molti anni ed essere in ottima salute, oppure essere recente e già un problema, perché scritto in fretta, senza test e senza documentazione.

Il punto non è l’età, ma il rapporto tra quanto ti serve e quanto è rischioso toccarlo.

I segnali che il software sta diventando un problema

• Ogni rilascio fa paura: si aggiorna il meno possibile, e quando lo si fa qualcosa si rompe altrove.
• Dipendenze obsolete: versioni del linguaggio, del framework o del database non più aggiornate, a volte non più installabili su server moderni.
• Performance in calo man mano che crescono i dati.
• Test assenti o insufficienti: nessuno sa con certezza cosa succede se si cambia una riga.
• Documentazione mancante: le regole di business stanno solo nel codice o nella testa di qualcuno.
• L’autore originale non è più disponibile, e chi subentra deve ricostruire tutto da zero.
• Le evoluzioni sono bloccate: richieste semplici, come un nuovo campo o un collegamento con un altro software, diventano lavori lunghi e incerti.

Uno solo di questi segnali non basta per decidere. Più se ne sommano, più è il momento di fare una valutazione seria.

Le opzioni a confronto

Opzione 1: continuare a mantenerlo

È un’opzione legittima, spesso sottovalutata. Se il software è stabile, fa ciò che serve e le richieste di modifica sono rare, mantenerlo può essere la scelta più sensata. Mantenere però non significa ignorarlo: aggiornare le dipendenze critiche, avere backup verificati, sapere dove sono le credenziali e come si rimette in piedi il sistema se il server si guasta.

Opzione 2: refactoring progressivo

Il refactoring è riorganizzare il codice senza cambiare cosa fa. Si procede a piccoli passi: si aggiungono test sulle parti più delicate, si separano le responsabilità, si sostituiscono le dipendenze obsolete. Ogni intervento si rilascia e si verifica prima del successivo.

È la strada giusta quando la struttura di base regge ma il codice è diventato difficile da leggere e modificare. Il limite è che non cambia la tecnologia di fondo: se il problema è lì, il refactoring da solo non basta.

Opzione 3: riscrittura

Riscrivere significa costruire un nuovo software che sostituisce il vecchio. Ha senso quando la tecnologia non è più sostenibile, quando il modo in cui l’azienda lavora è cambiato al punto che il vecchio modello non ha più senso, o quando ogni modifica costa più di quanto valga.

Anche in questi casi, però, conta molto come si riscrive.

Perché una riscrittura completa può essere rischiosa

La riscrittura «big bang», in cui si lavora a lungo sul nuovo sistema e poi un giorno si spegne il vecchio, ha rischi concreti:

• Logica implicita: un software che funziona da anni contiene regole che nessuno ricorda più, aggiunte per gestire un caso particolare. Se non vengono individuate, spariscono nel nuovo sistema.
• Regressioni: cose che funzionavano smettono di funzionare, e spesso lo si scopre solo dopo il passaggio.
• Doppia gestione: mentre si costruisce il nuovo, il vecchio va comunque mantenuto e magari modificato. Ogni modifica va fatta due volte.
• Transizione: il giorno del passaggio concentra tutti i rischi, dati compresi, in un solo momento.
• Valore che arriva tardi: finché il nuovo sistema non è completo, chi lo usa non vede nessun beneficio.

Migrazione progressiva e strangler pattern

Lo strangler pattern è un approccio noto per riscrivere senza big bang. Si individuano confini chiari nel sistema esistente, per esempio la gestione dei clienti, le prenotazioni o la fatturazione, e si sostituiscono uno alla volta. Il nuovo modulo prende il posto della parte corrispondente del vecchio, mentre il resto continua a funzionare. Col tempo il vecchio sistema si riduce fino a poter essere spento.

Richiede di far convivere i due sistemi per un periodo, quindi di avere confini ben definiti e un modo affidabile per farli comunicare: spesso è qui che entrano in gioco le API e le integrazioni tra software. In cambio, ogni passo è verificabile e il rischio è distribuito.

Database e migrazione dati

I dati sono spesso la parte più preziosa di un software legacy, e la più delicata. Prima di promettere che «si conserva tutto» serve un’analisi: com’è strutturato il database, quanto sono puliti i dati, se ci sono duplicati, campi usati in modo diverso da come erano stati pensati, informazioni salvate in formati non standard.

In genere la migrazione si prepara con script ripetibili, si prova più volte su copie dei dati reali e si verifica il risultato insieme a chi usa il sistema ogni giorno. Se il passaggio è progressivo, può servire anche sincronizzare i dati tra vecchio e nuovo per un periodo.

Come valutare tecnicamente un progetto esistente

Quando qualcuno mi chiede di intervenire su un software esistente, parto sempre da un’analisi del codice e del sistema prima di proporre qualsiasi strada. Gli aspetti che guardo:

• Accesso ai sorgenti: sono disponibili, completi e aggiornati rispetto a ciò che gira in produzione?
• Riproducibilità: si riesce a installare e avviare il sistema in un ambiente di test?
• Dipendenze: quali versioni, quanto sono datate, quali hanno problemi di sicurezza noti.
• Dati: struttura del database, qualità dei dati, backup esistenti.
• Test e log: cosa è già verificato automaticamente, cosa si riesce a osservare quando qualcosa va storto.
• Criticità: quali parti sono essenziali per il lavoro quotidiano e quali si possono toccare con meno rischio.
• Continuità: cosa succede se il sistema si ferma, e per quanto tempo l’azienda può farne a meno.

Il risultato è un quadro di cosa c’è, cosa è a rischio e quali opzioni sono realistiche, con priorità chiare. La decisione resta tua, ma presa su dati concreti.

Quando direi: non riscriviamolo

Ci sono casi in cui consiglierei di non riscrivere:

• il software fa bene il suo lavoro e i problemi sono localizzati;
• le difficoltà vengono da poche aree che si possono isolare e sistemare;
• non c’è un processo chiaro da cui ripartire, e una riscrittura rischierebbe di replicare la confusione attuale con una tecnologia nuova;
• l’azienda non può permettersi un periodo di transizione in questo momento.

In questi casi la manutenzione o il refactoring progressivo danno più valore con meno rischio, e lasciano aperta la possibilità di sostituire singole parti più avanti.

Se stai valutando cosa fare del tuo software, guarda come lavoro su manutenzione ed evoluzione di software esistenti oppure scrivimi per un’analisi del sistema attuale: prima di rifare tutto, analizziamo il software esistente e valutiamo il percorso di evoluzione. Se invece stai pensando a un nuovo sistema, può esserti utile capire da cosa dipende il costo di un gestionale su misura.

Domande frequenti

Quanto costa modernizzare un software?

Dipende dallo stato del codice, dalla quantità e qualità dei dati, dal numero di moduli da toccare e dalla strada scelta. Per questo il primo passo è l’analisi: senza conoscere il sistema, qualsiasi cifra sarebbe una supposizione.

È possibile cambiare tecnologia gradualmente?

Sì, ed è spesso la scelta più prudente. Con la migrazione progressiva si sostituisce un modulo alla volta, facendo convivere vecchio e nuovo finché il vecchio non serve più.

Si possono conservare i dati?

Spesso sì, ma non va dato per scontato: serve prima un’analisi del database e della qualità dei dati, e poi prove di migrazione su copie reali.