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.
| 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 |
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.