Come decidi quando fare il refactoring rispetto a riscrivere un sistema da zero?

Question

IT Interview Practice · Accepted Answer

Predefinisci il **refactoring**. Una riscrittura è giustificata solo quando il sistema esistente non può più evolvere per soddisfare i requisiti a un costo accettabile, e puoi continuare a consegnare valore mentre la fai. La maggior parte degli istinti del tipo "ci serve una riscrittura" è in realtà un problema di tech debt non gestito che il refactoring incrementale risolve con molto meno rischio.

## Come ragiono al riguardo

- **L'architettura di base è ancora valida?** Se il modello dei dati, i confini e il runtime possono allungarsi fino ai nuovi requisiti, fai il refactoring. Se le assunzioni fondamentali sono sbagliate (paradigma di storage errato, nessun modo di scalare, fine vita del linguaggio/piattaforma), una riscrittura diventa un candidato reale.
- **Qual è la frequenza di cambiamento?** Il codice che cambia raramente non ha bisogno di essere bello. Concentra lo sforzo dove il team lavora ogni giorno.
- **Capiamo il comportamento attuale?** Una riscrittura getta via anni di conoscenza di casi limite codificata. Se non ci sono test né una specifica, una riscrittura reintrodurrà vecchi bug.

## Un framework decisionale

| Segnale | Propende per il refactoring | Propende per la riscrittura |
| --- | --- | --- |
| L'architettura soddisfa i requisiti | Sì | No |
| Copertura test/specifiche | Bassa o alta | Abbastanza alta da verificare la parità |
| Si può rilasciare incrementalmente | Sì | Difficile, big-bang |
| Il team capisce il codice | Sì | No, e gli autori originali sono andati via |

## Trade-off

- **Refactoring:** rischio più basso, delivery continua, ma lento su una fondazione davvero marcia.
- **Riscrittura:** lavagna pulita, ma paghi una **tassa di blocco delle funzionalità**, ti porti dietro un **costo di doppia manutenzione** e rischi la classica trappola di over-engineering del secondo sistema.
- Preferisci la via di mezzo **strangler-fig**: alza il nuovo sistema accanto al vecchio, instrada il traffico in modo incrementale, elimina il vecchio pezzo per pezzo. Dà i benefici della riscrittura con il rischio del refactoring.

## Trappole

- Riscrivere per ragioni **estetiche o resume-driven**, non per costo di business.
- Sottostimare il comportamento nascosto; caratterizza sempre prima il comportamento attuale con i test.
- Una riscrittura big-bang di più trimestri che non rilascia nulla — slancio e fiducia crollano entrambi.

## Perché è importante

La scelta tra refactoring e riscrittura è una delle decisioni a più alta leva che un Tech Lead prende. Sbagliala verso la riscrittura e puoi congelare la delivery per un anno e fallire comunque; sbagliala verso il refactoring e perdi velocità lentamente. Inquadrarla come una decisione di costo e rischio, non di gusto, è ciò che separa il giudizio senior dalla preferenza.

Segnale	Propende per il refactoring	Propende per la riscrittura
L'architettura soddisfa i requisiti	Sì	No
Copertura test/specifiche	Bassa o alta	Abbastanza alta da verificare la parità
Si può rilasciare incrementalmente	Sì	Difficile, big-bang
Il team capisce il codice	Sì	No, e gli autori originali sono andati via

Come ragiono al riguardo

Un framework decisionale

Trade-off

Trappole

Perché è importante

Domande correlate