Cos'è il refactoring del codice

Capita a tutti: scrivi del codice di fretta, funziona, e lo lasci lì. Mesi dopo lo riapri e fatichi a capirlo. Il refactoring serve esattamente a questo: ripulire il codice rendendolo più chiaro, senza cambiare ciò che fa.

In questo articolo ti spiego cos'è il refactoring del codice, perché conta e ti mostro qualche tecnica con esempi prima/dopo.

Cos'è il refactoring in parole semplici

Il refactoring è il processo di ristrutturare il codice esistente per renderlo più leggibile, ordinato e manutenibile, senza modificarne il comportamento esterno. In altre parole: il programma fa esattamente le stesse cose, ma il codice dentro è migliore.

È come riordinare una stanza. Gli oggetti sono gli stessi, ma trovarli e usarli diventa molto più facile. Il refactoring non aggiunge funzionalità nuove: migliora la qualità di ciò che c'è già.

Perché farlo

Il codice "sporco" funziona, ma costa caro nel tempo. Ecco i vantaggi del refactoring:

• Leggibilità: chi lo legge (anche tu tra sei mesi) lo capisce in fretta.
• Manutenibilità: aggiungere funzioni o correggere bug diventa più semplice.
• Meno bug: codice ordinato nasconde meno trappole.
• Lavoro di squadra: un team lavora meglio su codice pulito.

Esempio: estrarre una funzione

Una delle tecniche più comuni è prendere un blocco di codice e dargli un nome trasformandolo in funzione. Guarda il prima:

# prima
prezzo = 100
if cliente == "premium":
    prezzo = prezzo - prezzo * 0.2
else:
    prezzo = prezzo - prezzo * 0.1
spedizione = 5 if prezzo < 50 else 0
totale = prezzo + spedizione

E il dopo, con funzioni dai nomi parlanti:

# dopo
def applica_sconto(prezzo, cliente):
    sconto = 0.2 if cliente == "premium" else 0.1
    return prezzo - prezzo * sconto

def calcola_spedizione(prezzo):
    return 5 if prezzo < 50 else 0

prezzo = applica_sconto(100, cliente)
totale = prezzo + calcola_spedizione(prezzo)

Il comportamento è identico, ma ora il codice si legge quasi come una frase.

Tecniche di refactoring comuni

• Rinominare variabili e funzioni con nomi chiari (x diventa totale_carrello).
• Estrarre funzioni per dare un nome a blocchi complessi.
• Eliminare duplicazioni: se copi-incolli lo stesso codice, estrailo una volta sola.
• Semplificare condizioni annidate troppo profonde.
• Rimuovere codice morto che non viene più usato.

Molti di questi principi sono parte integrante del clean code, un approccio che ti consiglio di approfondire subito dopo.

La regola d'oro: i test prima

C'è un rischio nel refactoring: rompere qualcosa che funzionava. Per questo la regola è chiara: prima di toccare il codice, assicurati di avere dei test che verificano il comportamento. Così, dopo ogni modifica, controlli in un istante che tutto funzioni ancora come prima.

Se hai i test, il refactoring diventa sicuro e quasi divertente. Senza test, ogni modifica è una scommessa.

Quando farlo (e quando no)

Il momento migliore per il refactoring è "mentre passi di lì": stai aggiungendo una funzione e noti del codice confuso vicino? Sistemalo. Questa abitudine si chiama "regola del boy scout": lascia il codice un po' più pulito di come l'hai trovato.

Evita invece di rifare tutto in blocco senza motivo, o di ottimizzare in modo ossessivo cose che funzionano benissimo. Il refactoring serve la leggibilità, non la perfezione fine a se stessa.

In sintesi

Il refactoring è il lavoro di migliorare la struttura del codice senza cambiarne il comportamento. Rende il software più leggibile, manutenibile e meno soggetto a bug. La chiave è procedere a piccoli passi, sempre protetti da test che ti dicono se hai rotto qualcosa.

Vuoi imparare a scrivere codice pulito fin dall'inizio, così da fare meno refactoring dopo? Lo trovi spiegato con esercizi pratici nei corsi di CodeGrind.