Come decidiamo quando rifattorizzare e quando riscrivere
Ogni sviluppatore si trova ad affrontare questo momento.
Il codebase è lento. L'aggiunta di funzionalità richiede troppo tempo. I nuovi assunti fanno fatica a comprendere il sistema. Qualcuno, alla fine, suggerisce una riscrittura completa.
Il team di solito si divide in due gruppi. Un gruppo vuole ricominciare da zero. L'altro teme il fallimento delle riscritture passate. Entrambe le parti hanno ragioni valide.
Una riscrittura non è una soluzione magica. Spesso richiede più tempo del previsto. Si finisce per dover mantenere due sistemi contemporaneamente. Si potrebbero persino ripetere gli stessi errori nella nuova versione.
Una riscrittura ha senso in questi casi specifici:
• Il modello dati è fondamentalmente errato per il business. • La tecnologia è obsoleta e non riceve più aggiornamenti di sicurezza. • Le esigenze del business sono cambiate così tanto che il sistema originale è ormai superato. • Nessuno nel team attuale comprende come funziona il sistema.
Anche in questi casi, non procedere con una sostituzione "big bang". Usa il pattern "strangler fig". Costruisci il nuovo sistema pezzo per pezzo, parallelamente al vecchio.
La maggior parte delle volte, in realtà, hai solo bisogno di rifattorizzare.
Il refactoring è la scelta giusta quando:
• È ancora possibile aggiungere funzionalità, anche se lentamente. • Il team comprende il codice attuale. • Il disordine è limitato a moduli specifici. • Il business non può smettere di rilasciare nuove funzionalità.
Prima di scegliere, chiediti perché il codice è diventato scadente.
Se il problema è il debito tecnico, rifattorizza le parti peggiori. Se il problema è la mancanza di code review o una cultura aziendale scadente, una riscrittura non aiuterà. Creerai solo un nuovo disordine con le solite vecchie abitudini.
Poni queste domande prima di decidere:
• Possiamo correggere le parti peggiori in modo isolato? • Il modello dati è inadeguato per le attuali esigenze di business? • Quali conoscenze perderemo se ricominciamo da capo? • Il business ha la stabilità necessaria per gestire una transizione lunga?
Ricominciare da capo dà una bella sensazione. Finire la riscrittura è la parte difficile. La maggior parte delle volte, un piano di refactoring strutturato è più sicuro ed efficace.
Fonte: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk