Quando riscrivere, quando fare refactoring

"Dobbiamo riscrivere tutto da zero."

L'ho detto. L'ho sentito dire. Sono stato quello che lo sosteneva e quello che cercava di dissuadere qualcuno dall'idea. La conversazione sulla riscrittura è una delle più cariche emotivamente nell'ingegneria del software — sembra una discussione tecnica, ma quasi mai lo è.

Ecco come ragiono io.

La riscrittura è quasi sempre una bugia che ti racconti

Non sempre. Ma di solito sì.

Il modello mentale dietro una riscrittura è che il codebase attuale sia il problema. Se si potesse ricominciare da zero — con tutto quello che sai ora, senza decisioni legacy, senza debito accumulato — la nuova versione sarebbe migliore e la costruiresti più in fretta.

Questo è quasi sempre falso. Il disordine da cui vuoi fuggire è di solito una combinazione di tre cose: decisioni genuinamente sbagliate prese all'inizio, complessità inevitabile dato il problema, e la tua comprensione incompleta del dominio quando hai cominciato. Una riscrittura non risolve la seconda o la terza. Le sposta soltanto.

Il vecchio codebase ha qualcosa che quello nuovo non ha: anni di edge case, bug fix, e maturità da produzione. I rami strani nel codice non sono incidenti — la maggior parte sono cicatrici. Li ricostruirai tutti, solo più lentamente.

Quando una riscrittura è davvero la scelta giusta

A volte lo è.

Il segnale non è "questo codice è disordinato." Il segnale è "le assunzioni incise in questa architettura non corrispondono più al problema." Quando la forma di quello che stai costruendo è cambiata così radicalmente che ogni nuova feature richiede di combattere la struttura esistente — non solo leggerla con attenzione, ma aggirarla attivamente — allora il codice non è debito tecnico. È il codice sbagliato.

Ho riscritto il motore di meeting in Clover e Argan — passando da un'architettura WebRTC + TURN server a mediasoup. Non perché l'originale non funzionasse. WebRTC con un TURN server funziona. Ma chi acquista una piattaforma di meeting self-hosted non vuole provisionare e mantenere un TURN server. Vuole qualcosa che funzioni out of the box.

La scelta tecnologica originale era diventata il vincolo — non perché non riuscisse a fare il lavoro tecnicamente, ma perché le assunzioni di deployment che richiedeva non corrispondevano a quello che gli utenti erano disposti a fare. È comunque un modello sbagliato. Vive solo a un livello diverso rispetto al codice.

Questa è la distinzione: modello sbagliato vs. implementazione disordinata. I modelli sbagliati richiedono riscritture. Le implementazioni disordinate richiedono refactoring.

Cosa significa davvero refactoring

Il refactoring viene usato male in continuazione. "Dovremmo fare refactoring" spesso significa "dovremmo sistemare questo" che spesso significa "non mi piace come è fatto."

Il vero refactoring è qualcosa di specifico: cambiare la struttura del codice senza cambiarne il comportamento, per rendere la prossima modifica meno costosa. Non è un fine in sé. È una tecnica per ridurre il costo di quello che stai davvero cercando di costruire.

Questa definizione conta perché dà un criterio di stop. Fai refactoring finché la prossima modifica diventa facile, poi ti fermi. Non continui finché il codice non sembra quello che scriveresti oggi. Quello è perfezionismo con un nome diverso.

I segnali che uso

Riscrivo quando:

• Il modello dati di base è sbagliato per come il prodotto viene effettivamente usato
• Ogni nuova feature richiede di toccare la stessa area rischiosa e poco compresa
• La scelta tecnologica originale è il vincolo — un framework che non può fare quello che serve, non uno che preferiresti diverso
• Il codice esistente non può essere testato in modo da darti fiducia nel modificarlo

Faccio refactoring quando:

• Capisco cosa fa il codice ma è difficile da cambiare
• Un'area specifica causa bug ripetuti che non esisterebbero con una struttura migliore
• Sto per aggiungere una feature significativa e l'approccio sarà più pulito con un po' di cleanup mirato

Lo lascio stare quando:

• Funziona e non ho bisogno di cambiarlo
• Non mi piace semplicemente come è fatto
• Qualcun altro l'avrebbe fatto diversamente

L'ultima categoria è dove si crea molto lavoro inutile.

La versione onesta

Quando gli ingegneri propongono riscritture, spesso è perché si sono annoiati a fare manutenzione, o vogliono usare una tecnologia diversa, o sentono che il vecchio codice li rappresenta male e vogliono ripartire senza quella storia.

Nessuna di queste è una buona ragione per riscrivere. Sono ragioni umane — le ho sentite tutte — ma non sono ragioni ingegneristiche.

La disciplina sta nell'essere onesti su quale delle due stai davvero seguendo. Se è un problema genuino di modello, una riscrittura può farti risparmiare mesi di lotta con l'astrazione sbagliata. Se è una preferenza travestita da principio, stai per spendere tempo significativo e creare rischio per finire più o meno dove eri.

Fatti la domanda: l'architettura è sbagliata, o sono semplicemente frustrato da essa? Di solito, qualche giorno di lavoro onesto te lo dirà.