Refactoring nell'Era AI

Evoluzione storica e ruolo futuro del refactoring secondo Martin Fowler (autore del libro Refactoring nel 1999 e della seconda edizione nel 2019, intervistato da The Pragmatic Engineer nel novembre 2025): con gli strumenti AI che generano enormi volumi di codice di qualità discutibile, la disciplina dei piccolissimi passi che preservano il comportamento diventa ancora più cruciale, ma richiede di combinare gli LLM con strumenti deterministici poiché i modelli da soli non sanno rifattorizzare in modo sicuro ed efficiente. ¹

Definizione rigorosa contro l'abuso del termine

Con il successo del libro di Fowler, "refactoring" è entrato nel vocabolario quotidiano dell'industria ma è stato orribilmente abusato: viene spesso usato per indicare qualsiasi modifica o riscrittura generica di un programma (come il classico collega che per giorni allo standup ripete "sto ancora facendo il refactoring"). ¹

Nella definizione rigorosa di Fowler, invece: ¹

• Piccolissimi passi che preservano il comportamento: il refactoring consiste esclusivamente in trasformazioni minuscole che preservano la semantica e il comportamento del programma (very small behavior-preserving changes). ¹
• Piccolezza e componibilità (smallness and composability): Fowler riassume l'essenza della pratica dicendo che ogni singolo passo è così piccolo che da solo non varrebbe la pena di farlo, ma concatenandoli in sequenza si riescono a compiere trasformazioni enormi senza mai rompere il sistema. ¹
• La disciplina è più veloce: benché possa sembrare controintuitivo, procedere in modo strutturato e controllato attraverso passi minuscoli è in realtà più rapido ed efficace delle grandi ristrutturazioni manuali e abbatte il costo complessivo di modifica del software nel tempo. ¹

Storia: da Chrysler C3 e dal Refactoring Browser a JetBrains

Fowler ripercorre la genesi del libro del 1999 e degli strumenti di refactoring automatico: ¹

1. La stanza d'albergo a Detroit con Kent Beck: Fowler incontra il refactoring lavorando con Kent Beck all'inizio del progetto Chrysler C3. In una stanza d'albergo a Detroit (al Courtyard), Beck gli mostra come rifattorizzava codice Smalltalk: Fowler — che aveva sempre tenuto molto alla comprensibilità sia della prosa sia del codice — resta folgorato nel vedere quanto fosse minuscolo ogni singolo passo e come, proprio grazie a quella piccolezza, i passi non andassero mai storti e si componessero splendidamente. Poiché Beck in quel momento aveva tutte le energie assorbite dalla stesura del primo libro su Extreme Programming (il White Book), Fowler decide di scrivere lui il libro sul refactoring, annotando con cura la meccanica passo-passo di ogni trasformazione (ad esempio come eseguire Extract Method senza sbagliare) e costruendovi attorno gli esempi in Java — scelto al posto dell'amato Smalltalk, che stava morendo, perché a fine anni '90 Java appariva come il linguaggio del futuro. ¹
2. Il Refactoring Browser in Smalltalk: Fowler precisa che il refactoring non fu inventato da Beck, ma sviluppato dal gruppo di Ralph Johnson alla University of Illinois at Urbana-Champaign, dove John Brant e Don Roberts realizzarono in Smalltalk il primo Refactoring Browser, capostipite di tutti i tool di refactoring automatico. ¹
3. Da VisualAge a IntelliJ IDEA e ReSharper: all'uscita del libro c'era già interesse nel team di IBM VisualAge (le cui prime versioni erano scritte proprio in Smalltalk), ma furono i creatori di JetBrains a coglierne fino in fondo il potenziale, integrando i refactoring automatici nelle prime versioni di IntelliJ IDEA e poi nel celebre plugin ReSharper per Visual Studio (per cui gli sviluppatori pagavano circa 200 dollari l'anno pur di poter rinominare classi e variabili in sicurezza tramite il grafo semantico del codice, funzione di cui si sentì acutamente l'assenza in Xcode ai primi tempi di Swift). Nonostante la comodità dell'automazione negli IDE, Fowler ricorda che resta prezioso saper eseguire i passi manualmente quando si lavora in linguaggi o su trasformazioni non coperti dai tool. ¹

La seconda edizione del 2019: perché JavaScript

Vent'anni dopo la prima edizione, nel 2019 Fowler pubblica una seconda edizione completamente aggiornata per due ragioni principali: ¹

• Rinfrescare un libro scritto nel Java di fine anni '90: pur restando valide le idee di fondo, gli esempi in Java degli anni '90 mostravano ormai la loro età; riscriverli serviva a dare al libro altri vent'anni di vita. ¹
• Dal centrismo object-oriented alle funzioni in JavaScript: Fowler sceglie di passare da Java a JavaScript sia per parlare a un pubblico più vasto, sia per descrivere il refactoring in modo meno centrato sull'object orientation (ad esempio trasformando Extract Method in Extract Function e includendo refactoring che non verrebbero spontanei in un linguaggio puramente a oggetti). ¹

Perché il refactoring diventa più importante con l'AI (e il limite nel brownfield)

Con l'arrivo degli strumenti di generazione del codice, ci troviamo con molto più codice scritto molto più in fretta: ¹

• Portare in buono stato codice discutibile che funziona: quando un LLM produce codice di qualità discutibile ma funzionante, la combinazione di test e refactoring è la via maestra per portarlo in una struttura pulita e comprensibile mantenendolo funzionante (vedi Slice Sottili e Ciclo di Feedback). ¹
• Gli LLM da soli non sanno rifattorizzare (l'aneddoto di James Lewis su Cursor): mentre nel greenfield l'esplorazione corre veloce, modificare in modo sicuro un sistema esistente (brownfield) con gli LLM resta un problema aperto. Fowler racconta l'esperimento fatto quella stessa mattina dal collega James Lewis, che per prova ha chiesto a Cursor di rinominare una classe in un programma nemmeno troppo grande: tornato dopo un'ora e mezza, ha scoperto che l'agente aveva bruciato il 10% della sua allocazione mensile di token solo per cambiare il nome di una classe — un'operazione che ReSharper eseguiva in modo istantaneo, economico e deterministico vent'anni prima. Inoltre, spiegare a parole un piccolo refactoring in una CLI come Claude Code richiede spesso più tempo che eseguirlo direttamente con le scorciatoie dell'IDE. ¹

Lo stato dell'arte: l'LLM come guida per strumenti deterministici

Poiché gli strumenti AI attuali non possono eseguire refactoring affidabili da soli a causa del non determinismo del software, la direzione più promettente consiste nell'ibridare gli LLM con strumenti deterministici (vedi anche Harness Engineering): ¹

• L'approccio di Adam Tornhill: Fowler cita il lavoro di Adam Tornhill, che combina gli LLM con altri strumenti di analisi e trasformazione del codice per ottenere un percorso molto più efficace rispetto all'uso del solo modello. ¹
• L'analogia con l'SQL e il caso 10% LLM / 90% tool deterministico: così come molti sviluppatori usano l'LLM per farsi generare una prima bozza di query SQL complessa che poi verificano e ritoccano a mano, nel refactoring su larga scala l'LLM può fornire l'innesco iniziale. Fowler ricorda il caso (di circa un anno prima) di una grande azienda che aveva celebrato una massiccia migrazione di API e pulizia del codebase presentandola come un successo degli LLM, salvo poi emergere che il lavoro era stato svolto per il 10% da un LLM e per il 90% da uno strumento deterministico di trasformazione del codice. ¹
• Vedere all'opera lo strumento deterministico: l'interazione davvero interessante consiste nell'usare l'LLM come punto di partenza per guidare e pilotare uno strumento deterministico, potendo così osservare e controllare con esattezza ciò che lo strumento deterministico sta eseguendo sul codice. ¹

Vedi anche: Non Determinismo del Software, Martin Fowler, Harness Engineering, Kent Beck, Slice Sottili e Ciclo di Feedback

Fonti e Riferimenti