Scorecard pronta per il consiglio: riscrivere o rifattorizzare, con casi svizzeri

Rifattorizza per impostazione predefinita. Riscrivi solo quando vincoli misurabili rendono impossibile il cambiamento incrementale. Il rischio, il costo e il sapere aziendale che si perdono in una riscrittura completa raramente ripagano rispetto all'alternativa fatta di miglioramenti piccoli e verificabili. La domanda che decide tutto è una sola: modifiche piccole e testabili bastano a soddisfare il vincolo di business che hai? La griglia di punteggio qui sotto trasforma quella domanda in una risposta difendibile.

---

In breve:

• Prima di rifattorizzare o riscrivere, costruisci una matrice decisionale che consideri criticità per il business, accoppiamento dei dati, copertura dei test, rischio di rilascio, capacità del team, costi operativi e vincoli legali.

• Il refactoring è la scelta migliore quando esistono punti di separazione, la copertura dei test è sufficiente e il tempo per arrivare al valore è breve, soprattutto se il comportamento è protetto dai test; una riscrittura si giustifica solo se le modifiche incrementali non possono fornire le funzionalità necessarie.

• Le riscritture vanno delimitate, tenute brevi e guidate da criteri di uscita chiari, con prove che una migrazione parziale non può soddisfare le esigenze tecniche o normative, evitando decisioni emotive.

• I modelli incrementali come lo Strangler Fig permettono di sostituire i sistemi legacy funzione per funzione o dominio di dati per dominio di dati, a condizione che siano presenti osservabilità e meccanismi di rollback.

• Gli ingegneri senior devono presidiare il processo decisionale, assicurando che la valutazione si basi su prove come copertura dei test, punti di separazione e rischio di rilascio, e non su preferenze o impressioni datate.

---

Una matrice decisionale ponderata per scegliere tra riscrittura e refactoring

Un'opinione singola raramente sopravvive a una riunione del consiglio. Una matrice a punteggio sì. Assegna a ogni fattore un valore da 1 (a favore del refactoring) a 5 (a favore della riscrittura), poi applica i pesi che riflettono ciò che minaccia davvero la tua azienda.

• Criticità per il business: quanto fatturato o quanta esposizione normativa dipendono da questo sistema in questo momento.

• Accoppiamento dei dati: quanto lo schema e la logica di business sono fusi insieme e se puoi separarne uno senza toccare l'altro.

• Copertura dei test: la percentuale di percorsi critici coperti da test automatici di cui ti fidi.

• Rischio di rilascio e di rollback: quanto velocemente puoi mandare in produzione una modifica e annullarla se rompe qualcosa.

• Capacità del team: se hai ingegneri senior liberi per condurre una migrazione di diversi mesi senza lasciare a secco il resto del lavoro.

• Costo operativo: il carico di manutenzione attuale, misurato in ore per sprint o in franchi per trimestre.

• Vincoli legali o normativi: se una normativa, una regola sulla residenza dei dati o un requisito di audit impediscono del tutto il cambiamento incrementale.

Dai il peso maggiore alla criticità per il business e ai vincoli legali, perché sono quelli che comportano le conseguenze peggiori se sbagli la scelta.

Un punteggio complessivo sotto il 2,5 circa indica il refactoring. Un punteggio tra 2,5 e 3,5 suggerisce un approccio Strangler Fig: sostituzione incrementale dietro uno strato di instradamento. Sopra il 3,5, con prove a conferma su almeno due fattori, una riscrittura delimitata diventa difendibile. Raccogli numeri reali prima di assegnare qualsiasi punteggio: percentuale di copertura dei test unitari, tempo medio di consegna delle modifiche, frequenza dei rilasci e costo di manutenzione documentato per trimestre. Una griglia costruita su supposizioni è solo un'opinione con un foglio di calcolo allegato.

Quando i segnali indicano il refactoring

La maggior parte dei sistemi che sembrano irrecuperabili sono in realtà solo poco testati. Il refactoring vince quando valgono queste condizioni:

1. I punti di separazione esistono già, oppure si possono creare in giorni invece che in mesi, permettendoti di isolare e modificare un modulo senza toccare il resto.

2. Il rilascio incrementale è praticabile: puoi pubblicare una modifica dietro un flag e tornare indietro in pochi minuti.

3. La copertura dei test sui percorsi critici è sufficiente, oppure aumentarla è uno sforzo delimitato e stimabile, non uno sforzo senza fine.

4. In questo momento la correttezza del comportamento conta più della purezza del design interno. Gli utenti non notano un'architettura pulita; notano i disservizi.

5. Il tempo per arrivare al valore è breve e il tuo team o il tuo budget non possono assorbire una riscrittura lunga più trimestri senza bloccare altre priorità.

Un modulo di elaborazione dei pagamenti con interni disordinati ma una buona copertura dei test è il classico candidato al refactoring: il rischio sta nel comportamento, non nella struttura, e il comportamento è già protetto dai test.

Consiglio pratico: prima di assegnare qualsiasi punteggio, verifica se riesci a scrivere un test che passa per il comportamento che stai per toccare. Se non ci riesci, quello è il tuo primo progetto, non la riscrittura.

Quando la riscrittura è davvero la scelta difendibile

Una riscrittura si merita il suo costo solo in condizioni ristrette e supportate da prove, non perché il codice sembra vecchio o perché a un nuovo ingegnere non piace il framework.

• L'architettura attuale impedisce una funzionalità di cui l'azienda ha realmente bisogno e non esiste alcun percorso incrementale per aggiungerla.

• Il modello dei dati o un requisito normativo non può essere migrato in sicurezza a fette, quindi gli stati parziali lascerebbero il sistema non conforme o incoerente.

• Non esiste alcun punto di separazione praticabile nel codice e l'accoppiamento tra i componenti è così fitto che isolarne uno rischia di romperli tutti.

• Una riscrittura per fasi può essere delimitata con precisione, finanziata per una finestra breve e definita e rilasciata con criteri di uscita espliciti, invece che con un mandato aperto del tipo «capiremo quando è finita».

Se il tuo caso non soddisfa almeno due di questi punti, stai scegliendo la riscrittura per ragioni emotive, non tecniche. È l'errore più costoso di questo elenco.

Strangler Fig e altri modelli di modernizzazione incrementale

Il Strangler Fig pattern, documentato da Martin Fowler, sostituisce il comportamento del sistema legacy a fette piccole e testabili invece che con un unico passaggio. Ogni fetta va in produzione, si dimostra valida sul campo e solo allora inizia la fetta successiva: così una scommessa ad alto rischio diventa una serie di scommesse a basso rischio.

Tre varianti coprono la maggior parte delle migrazioni reali:

• Instradamento tramite API gateway: uno strato facciata invia il traffico al sistema legacy o al nuovo componente in base al percorso, permettendoti di passare al nuovo sistema funzione per funzione.

• Estrazione funzione per funzione: estrai una capacità alla volta dal monolite, partendo dalla funzione con il rischio più basso e l'attrito più alto.

• Suddivisione dei dati: migri un dominio di dati alla volta, lasciando il resto sullo schema legacy finché non arriva il suo turno.

Niente di tutto questo funziona senza osservabilità, feature flag, rollback rapido e scritture in ombra che ti permettano di confrontare il comportamento nuovo e quello vecchio prima di affidarti solo al nuovo percorso.

Quanto costano davvero le riscritture e come tenere sotto controllo il rischio

Il costo reale di una riscrittura raramente compare nella stima iniziale. Dominano tre fattori: far girare entrambi i sistemi in parallelo mentre il nuovo recupera terreno, il tempo degli sviluppatori diviso tra nuove funzionalità e lavoro di migrazione e lo sforzo di riconciliazione necessario per confermare che il nuovo sistema produce gli stessi risultati del vecchio.

• Definisci i criteri di uscita di qualsiasi esecuzione in parallelo prima di avviarla: metti per iscritto le soglie di corrispondenza, una finestra di riconciliazione e punti di approvazione espliciti.

• Usa le scritture in ombra, così il nuovo sistema elabora traffico reale senza servirlo: ottieni una validazione equivalente alla produzione prima del passaggio definitivo.

• Automatizza la riconciliazione tra i risultati vecchi e nuovi invece di controllarli a mano, cosa che non regge oltre le prime settimane.

• Attenzione all'effetto secondo sistema: una riscrittura tende ad accumulare perimetro perché gli ingegneri vogliono sistemare tutte le vecchie lamentele in una volta sola, ed è così che un progetto di tre mesi diventa di un anno.

Il debito tecnico ha un tasso d'interesse misurabile. Una Research replicating developer productivity impact rileva che il debito tecnico aumenta il tempo che gli sviluppatori dedicano a test, analisi e refactoring, cioè esattamente il costo che stai cercando di evitare scegliendo il percorso di migrazione sbagliato. La DORA’s 2024 research aggiunge un avvertimento più netto: l'adozione dell'IA da sola è risultata correlata a un lieve calo della produttività di consegna e della stabilità delle consegne, il che significa che gli strumenti non possono sostituire le basi, cioè lotti di lavoro piccoli e test solidi durante una migrazione.

Una scorecard e una checklist da usare già questa settimana

Porta questi punti alla prossima riunione di pianificazione, invece di una presentazione piena di opinioni; valuta anche di integrare spunti da backlog refinement in Scrum per rendere più sicuri il refactoring e la modernizzazione incrementale.

• Soglia di copertura dei test: verifica la copertura sui percorsi critici che stai per toccare e fissa un minimo prima di iniziare il lavoro di migrazione.

• Individuazione dei punti di separazione: elenca ogni confine tra moduli già esistente o creabile entro due sprint.

• Piano di rollback: scrivi, in un paragrafo, esattamente come annulli la prima modifica in produzione.

• Stima del costo dell'esecuzione in parallelo: quantifica il costo di far girare entrambi i sistemi per tutta la durata della finestra di migrazione prevista.

• Punti di approvazione degli stakeholder: stabilisci per iscritto, prima di iniziare, chi approva il passaggio dalle scritture in ombra al cambio definitivo.

Dai un punteggio a ogni fattore della matrice qui sopra, somma il risultato ponderato e lascia che sia la soglia a decidere il percorso: sotto 2,5 significa refactoring, tra 2,5 e 3,5 significa strangler, sopra 3,5 con prove a conferma significa riscrittura delimitata.

Come funziona nella pratica un lavoro guidato da ingegneri senior

Decisioni come questa tendono ad andare storte quando chi assegna i punteggi non c'era quando il sistema è stato costruito e non ci sarà per mantenere ciò che lo sostituirà. I nostri ingegneri senior restano coinvolti nei progetti dalla prima consulenza fino alla consegna, per garantire continuità di giudizio.

• Il nostro caso studio di Habitects AG mostra una migrazione tecnica a responsabilità completa in cui la scelta tra estrazione incrementale e riscrittura delimitata è stata fatta sulla base del tipo di prove descritte in questo schema, non su una preferenza per la tecnologia nuova.

• Il nostro lavoro di migrazione legacy e cambio di piattaforma e i nostri mandati di due diligence tecnica applicano la stessa griglia prima di consigliare l'uno o l'altro percorso.

Come aiutiamo i team a scegliere e percorrere la strada giusta

Conduciamo audit e sprint di analisi che valutano il tuo sistema esattamente sui fattori descritti sopra: copertura dei test, punti di separazione, rischio di rilascio e accoppiamento dei dati, così la decisione tra riscrittura e refactoring poggia su prove e non sull'istinto. Quando la risposta è la modernizzazione incrementale, il nostro lavoro di migrazione legacy e cambio di piattaforma rende operativo lo Strangler Fig, con scritture in ombra e riconciliazione previste fin dal primo giorno. Quando la risposta onesta è una riscrittura delimitata, i nostri ingegneri senior restano sul progetto dalla prima conversazione di definizione fino alla consegna. Guarda la nostra pagina dei prezzi per le opzioni di collaborazione Guidance e Intensive, oppure dai un'occhiata ai nostri casi studio per vedere come questo schema ha funzionato su progetti reali.

Domande frequenti

Qual è la differenza tra refactoring e riscrittura?

Il refactoring modifica la struttura interna di un sistema con passi piccoli e testati, mantenendone invariato il comportamento esterno. La riscrittura sostituisce il sistema per intero, di solito partendo da una nuova base di codice o da una nuova architettura, con rischi e costi molto superiori rispetto al cambiamento incrementale.

Che cosa significa rifattorizzare?

Rifattorizzare significa ristrutturare il codice esistente per migliorarne il design, la leggibilità o la manutenibilità senza cambiare ciò che fa visto dall'esterno. I test confermano che il comportamento resta costante mentre gli interni migliorano.

Quali sono i sinonimi di «rifattorizzare»?

Le alternative più comuni sono «ristrutturare», «ripulire» o «modernizzare in modo incrementale», anche se nessuna rende la disciplina dei test che distingue un vero refactoring da una riscrittura improvvisata di una piccola sezione. Nella pratica i team usano «refactoring» proprio per segnalare che il comportamento è protetto dai test per tutta la durata della modifica.

ChatGPT è bravo a rifattorizzare il codice?

Gli strumenti di IA possono accelerare le attività meccaniche di refactoring, come rinominare, estrarre funzioni o suggerire pattern più puliti, ma non sostituiscono la disciplina di test e revisione che rende sicuro il refactoring. Il rapporto DORA del 2024 ha rilevato che l'adozione dell'IA da sola è correlata a una minore produttività e stabilità delle consegne, a conferma che sono le pratiche di base, come lotti di lavoro piccoli e una buona copertura dei test, a sostenere la migrazione, non lo strumento.

Quando conviene scegliere un approccio Strangler Fig invece di uno dei due estremi?

L'approccio Strangler Fig è adatto quando il punteggio della tua matrice decisionale finisce nella fascia intermedia: esistono alcuni punti di separazione ma l'accoppiamento è ancora rilevante, oppure la copertura dei test è parziale e non completa. Ti permette di sostituire il sistema a fette, validandone ognuna in produzione prima di passare alla successiva: è questo il motivo per cui la descrizione originale di Martin Fowler lo presenta come l'opzione predefinita a rischio più basso rispetto a una riscrittura completa.

Fonti

• DORA’s 2024 research

• Strangler Fig pattern

• Research replicating developer productivity impact

Consigliati

• Casi studio, progetti software svizzeri

• Habitects AG: la gestione completa della parte tecnica di una piattaforma per ristrutturazioni di bagni, fino alla fusione.

• Die Mitte: oltre 600 siti web di un partito politico svizzero gestiti da un unico sistema.

• Repa Immobiliare: portare un portafoglio immobiliare fuori dalla carta, con un software che non va mai online.