Refactoring

Summary Refactoring, tecnica per ristrutturare una porzione di codice, alterandone la struttura senza modificarne il comportamento.

Pubblicato nella Rubriki Numero 0 - 30 Nov 2005 da AndreaBoschin

Il Refactoring è una pratica di sviluppo, il cui scopo fondamentale è di migliorare la struttura del codice, per favorire il riutilizzo di porzioni di esso, per migliorarne la leggibilità e prepararne l'evoluzione. Il Refactoring, spesso associato alle MetodologieAgili perchè propedeutico alla loro applicazione, è una disciplina che se utilizzata con costanza permette di evitare che continui interventi nel codice siano fonte di ridondanze e confusione che portano inevitabilmente alla impossibilità di continuare con ulteriori evoluzioni. In quest'ottica si comprende che il Refactoring è indispensabile per l'adozione di tecniche di sviluppo agili, che richiedono appunto che il codice sia predisposto ad accettare continue modifiche per venire incontro a nuove esigenze introdotte dalla natura evolutiva di tali pratiche.

Il principio fondamentale sul quale si basa il Refactoring, è riassunto molto bene dalla definizione che ne da Martin Fowler, primo fra tutti a teorizzare tale pratica: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. In sostanza, cardine del Refactoring è la necessità di modificare una porzione di codice, possibilmente di dimensioni limitate, senza alterare il compito che essa svolge. Un esempio pratico di questo concetto è il caso in cui si decida di intervenire isolando alcune righe di codice che si ritiene necessario rendere disponibili in più punti dell'applicazione, trasformandole in un metodo. Questa semplice operazione, che durante l'estensione di codice si ripete spesso e volentieri per evitare duplicazioni, dimostra chiaramente qual'è il metodo che si dovrebbe applicare nella pratica del Refactoring. Il codice, dapprima monolitico ma funzionante, dopo l'estrazione del metodo continua a mantenere invariata la medesima funzionionalità, ma acquista una proprietà in più ovvero una struttura che consente di propagare la sua funzionalità in più punti.

Quando usare il Refactoring

Pur essendo il Refactoring una pratica indiscutibilmente utile, è sostanzialmente impossibile applicarlo in modo ininterrotto. Tipicamente lavorando ad una applicazione ci si troverà nella condizione di scrivere del codice inizialmente poco pulito ma che assolve al proprio compito in modo efficace. In seguito però esso dovrà essere migliorato con interventi di Refactoring per fare si che acquisti una flessibilità conferitagli da un buon design. Ecco quindi che è importante individuare il momento in cui è necessario iniziare una sessione di Refactoring.

Ancora una volta, è lo stesso Martin Fowler a suggerire nel suo libro - Refactoring: Improving the Design of Existing Code - un possibile approccio per decidere quando iniziare una sessione di Refactoring. Ecco espressa dalle sue parole quella che egli stesso ha denominato "Rule of Three": The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor. (La prima volta che fai qualcosa, semplicemente la fai. La seconda volta che farai qualcosa di simile, probabilmente di malavoglia la duplicherai comunque. La terza volta che farai qualcosa di simile sarà arrivato il momento di compiere il Refactoring)

Vi sono sostanzialmente due approcci per operare del refactoring. La prima, enunciata nei paragrafi precedenti ha lo scopo di migliorare il codice esistente. Essa inizia immediatamente dopo aver aggiunto una nuova funzionalità al codice per ristrutturarlo ed eliminare le "code smells", cioè le parti di codice che non appaiono ben strutturare e potrebbero essere causa in futuro di difficoltà nella manutenzione e nell'evoluzione. Questo tipo di Refactoring ha il pregio di lasciare sempre il codice in una condizione ideale. Si suddividerà quindi lo sviluppo di una nuova funzionalità in due fasi: la fase uno in cui ci si concentra nel raggiungimento dell'obbiettivo senza fare troppo caso alla pulizia del codice. Al termine, nella seconda fase si opera il Refactoring per riorganizzare e ristrutturare quanto appena introdotto.

Il secondo metodo con cui operare il Refactoring è l'attività propedeutica all'aggiunta di nuove funzionalità. Tipicamente, esaminando il codice di una applicazione è normale individuare delle operazioni di Refactoring che preparano il codice ad ospitare le nuove funzionalità. L'estrazione di un metodo, la creazione di una classe base, lo spostamento di un metodo da una classe superiore ad una inferiore sono tutte attività che preparano il codice creando gli agganci necessari per le funzionalità da introdurre. Una buona attività di Refactoring "preventivo" può condurre facilmente ad un notevole risparmio di tempo nella realizzazione di nuove feature.

Inutile dire che un approccio non esclude l'altro. Tipicamente il processo sarà misto, con una fase di refactoring preparatorio, uno sviluppo incontrollato e una fase finale di ristrutturazione.

Pattern di Refactoring

Così come nella pratica dello sviluppo di software si è sentita la necessità di formalizzare dei DesignPattern con lo scopo di individuarne più facilmente l'utilizzo, anche nel caso del Refactoring si è arrivati a definire un certo numero di pattern che cercano di dare una coerenza a questa disciplina. Nell'elenco che segue viene data una definizione minimale di alcuni di essi:

Il CatalogoDeiPatternDiRefactoring

Le "Code Smell"

Come già detto nei paragrafi precedenti uno degli scopi del refactoring è quello di eliminare le Code Smell, letteralmente le puzze del codice può essere tradotto anche come i cattivi odori del codice o in gergo le urla di dolore del codice.

Il CatalogoDelleCodeSmell

Strumenti di Refactoring

I ToolSoftwareDiRefatoring

Letture consigliate

Il sito di Martin Fowler sul Refactoring

Refactoring: Improving the Design of Existing Code - Martin Fowler, Addison-Wesley Professional - 1999