Refactoring: cos’è, obiettivi e tecniche di refactoring nello sviluppo

Cosa significa effettuare refactoring nella programmazione

Effettuare refactoring è il processo di modifica della struttura interna del codice software per migliorarne le caratteristiche di qualità senza modificarne il comportamento osservabile. Il termine è stato introdotto nell’uso diffuso da Martin Fowler nel 1999, e la pratica stessa è diventata uno dei fondamenti dello sviluppo agile e della programmazione estrema.

La caratteristica principale del refactoring è la conservazione della funzionalità. Dopo il refactoring, il programma deve eseguire esattamente le stesse azioni e restituire gli stessi risultati di prima delle modifiche. La garanzia di ciò sono i test automatizzati, che vengono eseguiti dopo ogni micropasso di refactoring. Se i test sono verdi — il comportamento è conservato. Se sono rossi — il refactoring è stato eseguito in modo errato o ha modificato il comportamento, il che significa che non si tratta più di refactoring ma di una modifica della funzionalità.

Esiste un equivoco persistente nel settore: qualsiasi riparazione del codice viene chiamata refactoring. In realtà, riscrivere il codice con modifiche comportamentali è una “riscrittura” o “rielaborazione”, non refactoring. La differenza è fondamentale: il refactoring è un processo controllato e sicuro, mentre riscrivere con modifiche logiche è un nuovo sviluppo completo con tutti i rischi associati.

La capitalizzazione della conoscenza sul refactoring nell’ambiente italofono avviene attraverso gli stessi meccanismi degli altri termini informatici: il calco dall’inglese “refactor” con l’aggiunta del suffisso verbale italiano. I programmi educativi in Ingegneria del Software e le traduzioni di libri hanno consolidato questo termine nel lessico professionale.

Refactoring vs Riscrittura

È importante distinguere il refactoring da una riscrittura completa del codice. Il refactoring è una serie di piccole trasformazioni sicure, ciascuna delle quali preserva il comportamento. La riscrittura consiste nel creare una nuova implementazione da zero, spesso con cambiamenti di architettura, tecnologie e comportamenti. La ricerca dello Standish Group (2023) mostra che i progetti che scelgono una riscrittura completa falliscono nel 40% dei casi, mentre i progetti che praticano il refactoring regolare hanno un debito tecnico inferiore del 25%.

Perché fare refactoring del codice: obiettivi principali

Il refactoring risolve diversi compiti chiave, ciascuno dei quali influisce direttamente sulla velocità e sul costo dello sviluppo. Comprendere questi obiettivi aiuta il team a stabilire correttamente le priorità e a giustificare il tempo dedicato al refactoring di fronte alle parti interessate.

Migliorare la leggibilità e la comprensibilità

Il codice viene scritto una volta ma letto decine e centinaia di volte. Se uno sviluppatore impiega 30 minuti per capire cosa fa una funzione — è una perdita diretta di produttività. Il codice leggibile riduce il carico cognitivo e accelera l’inserimento di nuovi membri del team. Tecniche come Rename Method, Extract Variable e Introduce Explaining Variable mirano proprio a migliorare la chiarezza del codice. Secondo una ricerca di Developer Productivity (Microsoft Research, 2023), gli sviluppatori trascorrono fino al 60% del tempo a leggere codice piuttosto che a scriverlo, rendendo la leggibilità uno dei principali fattori di produttività.

Eliminare la duplicazione

Il principio DRY (Don’t Repeat Yourself) è uno dei fondamenti della programmazione. La duplicazione del codice porta a dover apportare la stessa modifica in più punti, aumentando il rischio di errori e modifiche dimenticate. Il refactoring con le tecniche Extract Method e Pull Up Method elimina la duplicazione e centralizza la logica.

Ridurre la complessità

Le metriche di complessità ciclomatica e profondità di annidamento sono direttamente correlate al numero di difetti nel codice. Se una funzione ha una complessità ciclomatica superiore a 10-15, è difficile da testare e facile da rompere. Il refactoring con Replace Conditional with Polymorphism, Decompose Conditional e Extract Method riduce la complessità a un livello controllabile. La ricerca NIST (2024) mostra che i moduli ad alta complessità contengono 2-3 volte più difetti per mille righe di codice.

Prepararsi ai cambiamenti

Uno dei motivi principali del refactoring è la necessità di aggiungere nuove funzionalità. Se la struttura attuale del codice non consente di apportare una modifica senza rompere il comportamento esistente, il refactoring aiuta a preparare il terreno. La “regola del campeggio” (lascia il codice più pulito di come lo hai trovato) è una delle raccomandazioni di Martin Fowler che trasforma il refactoring da un’attività occasionale in una pratica costante.

I dati di un’analisi di 500 progetti open-source su GitHub (IEEE Transactions on Software Engineering, 2024) mostrano che i progetti con refactoring regolare hanno il 30% in meno di “code smells” e un indicatore di debito tecnico inferiore del 15% rispetto ai progetti in cui il refactoring viene eseguito solo occasionalmente.

Principali tecniche di refactoring

Martin Fowler ha catalogato più di 70 tecniche di refactoring nel suo libro. In pratica, la maggior parte dei team utilizza regolarmente 10-15 di esse. Esaminiamo le tecniche chiave che ogni sviluppatore dovrebbe conoscere.

Extract Method

La tecnica più frequentemente utilizzata. Se una sezione di codice può essere semanticamente estratta in una funzione separata — dovrebbe essere fatto. Extract Method migliora la leggibilità, consente di dare un nome all’operazione e semplifica il testing. La regola: se vedi un commento che spiega cosa fa un blocco di codice — quel blocco può essere estratto in un metodo separato.

// Prima del refactoring
double total = amount * price;
double discounted = total * (1 - discountRate);
double tax = discounted * taxRate;

// Dopo il refactoring
double total = calculateTotal(amount, price);
double finalPrice = applyDiscountAndTax(total);

Rename Variable / Rename Method

Il nome dovrebbe riflettere l’essenza. Se il nome di una variabile o metodo non risponde alla domanda “cosa viene memorizzato/fatto qui” — deve essere rinominato. Gli IDE moderni rendono questa operazione banale. I nomi puliti sono il modo più economico ed efficace per migliorare il codice.

Replace Conditional with Polymorphism

Quando la logica condizionale è cresciuta ed è diventata confusa, il polimorfismo offre un’alternativa più pulita. Invece di uno switch-case per tipo — creare una gerarchia di classi con un metodo sovrascritto. Il polimorfismo rende il codice estensibile: l’aggiunta di un nuovo tipo non richiede la modifica delle condizioni esistenti, ma solo la creazione di una nuova sottoclasse.

// Prima del refactoring (condizionali)
if (type.equals("email")) {
    sendEmail(message);
} else if (type.equals("sms")) {
    sendSms(message);
}

// Dopo il refactoring (polimorfismo)
Notifier notifier = new EmailNotifier();
notifier.send(message);

Introduce Parameter Object

Quando una funzione accetta troppi parametri (più di 3-4), sono difficili da leggere e passare. Raggruppare i parametri correlati in un oggetto parametro accorcia la firma, migliora la leggibilità e semplifica le modifiche future.

Quando fare refactoring e quando no

La decisione di fare refactoring non è tecnica ma gestionale. Richiede un equilibrio tra la produttività attuale e la salute a lungo termine della base di codice. Esaminiamo le situazioni tipiche in cui il refactoring è giustificato e quando è meglio astenersi.

Quando fare refactoring

La prima situazione — non capisci il codice che devi modificare. Se comprendere il codice esistente richiede più tempo che implementare nuove funzionalità — questo è un segnale per fare prima refactoring. La seconda situazione — hai trovato duplicazione che rallenta lo sviluppo e aumenta il rischio di errori. La terza — aggiungere nuove funzionalità è impossibile senza alterare la struttura esistente.

Vale anche la pena fare refactoring quando la base di codice contiene “code smells”: metodi lunghi, classi grandi, commenti eccessivi, catene di chiamate, gerarchie di ereditarietà parallele. Il catalogo dei code smells dal libro di Fowler contiene più di 20 indicatori tipici di problemi, ciascuno con una tecnica di refactoring corrispondente.

Quando non fare refactoring

Il refactoring non è necessario se il codice funziona stabilmente e non si prevede di modificarlo. Il principio “se non è rotto, non ripararlo” (if it ain’t broke, don’t fix it) è particolarmente rilevante per il codice che viene modificato raramente. Il refactoring fine a se stesso è una forma di perfezionismo ingegneristico che fa più male che bene.

Inoltre, non si dovrebbe fare refactoring del codice che verrà completamente sostituito nel prossimo futuro. Se il team prevede di riscrivere il modulo in un altro linguaggio o architettura, fare refactoring della versione attuale è una perdita di tempo. E infine, fare refactoring senza test è un’avventura, specialmente se la base di codice è grande e complessa. L’eccezione sono le trasformazioni semplici tramite IDE che possono essere annullate.

Come fare refactoring senza rischi per il progetto

Il refactoring sicuro è una disciplina. Esistono diversi principi la cui osservanza minimizza i rischi e rende il processo prevedibile. Il primo e più importante — refactoring solo sotto test. Se non hai test che coprono il codice da modificare — scrivili prima.

Il secondo principio — piccoli passi. Ogni operazione di refactoring dovrebbe essere minima: rinominare una variabile, estrarre un metodo, estrarre una classe. Dopo ogni passo — compilare ed eseguire i test. La suddivisione in micropassi consente di rilevare immediatamente un errore e annullare l’ultima modifica. Secondo Martin Fowler, i micropassi rendono il refactoring 3-4 volte più sicuro rispetto ai grandi cambiamenti.

Il terzo principio — utilizzare strumenti. Gli IDE moderni (IntelliJ IDEA, VS Code, Eclipse) forniscono refactoring automatizzati: rinomina, estrai metodo, estrai variabile, sposta classe e decine di altri. I refactoring basati su strumenti garantiscono la correttezza della trasformazione e non richiedono la ricerca manuale di tutti i punti in cui il codice deve essere modificato.

Il quarto principio — non mescolare il refactoring con le modifiche funzionali. Se fai refactoring e aggiungi nuova logica contemporaneamente, è impossibile determinare quale modifica abbia causato un errore. Separare i commit in “refactoring” e “funzionalità” è uno standard del settore che semplifica la revisione del codice e l’annullamento delle modifiche. La struttura raccomandata: prima un commit di refactoring (solo modifiche strutturali, comportamento preservato), poi un commit con la nuova funzionalità.

Flusso Git per il refactoring: crea un ramo separato, esegui il refactoring, ottieni test verdi, fai commit, poi aggiungi la nuova funzionalità nello stesso ramo. Se qualcosa va storto — le modifiche di refactoring possono sempre essere annullate tramite git revert.

# Micropassi di refactoring in Git
git checkout -b refactor/extract-payment
# Passo 1: estrarre metodo di calcolo
# ...modifiche... → compilare → test
git commit -m "refactor: extract calculatePayment method"
# Passo 2: rinominare variabili
# ...modifiche... → compilare → test
git commit -m "refactor: rename amount to grossAmount"