Quando si scrivono applicazioni e programmi in genere si cerca di partire sempre con il piede giusto prestando particolare attenzione alla struttura del codice per avere sorgenti “puliti” e facilmente mantenibili da noi o da terze parti. Si scrive quindi con un occhio di riguardo al futuro cercando di scrivere codice migliore e più aperto possibile. Tuttavia è pressochè certo che durante la fase di sviluppo (e non durante la progettazione o la stesura delle specifiche) il committente varierà le specifiche iniziali o i tempi ed i modi in cui vuole che la sua applicazione venga realizzata. Questo porterà inesorabilmente il programmatore di inserire parti di codice non previste, sviluppate in poco tempo e contro i propri consigli che andranno a degradare la qualità del codice prodotto facendogli perdere leggibilità ed apertura a modifiche future.

Purtroppo visto che i tempi da dedicare allo sviluppo sono sempre inferiori a quelli che realmente servirebbero per scrivere delle applicazioni in modo pulito e ragionato non è possibile concentrarsi contemporaneamente sulla scrittura del codice e sul suo refactoring. Quando impegnarsi quindi per migliorare il design del proprio codice? Esisteranno sicuramene molte scuole di pensiero a riguardo (se ve ne piace qualcuna in particolare ditecelo pure nei commenti) ma quella che preferisco è quella teorizzata da Fowler come “La regola del 3” (Rule of Three):

La prima volta che fai qualcosa, semplicemente la fai. La seconda volta che farai qualcosa di simile, probabilmente controvoglia la duplicherai comunque. La terza volta che farai qualcosa di simile sarà arrivato il momento di compiere il refactoring.

Gli approcci alle attività di refactoring sono sostanzialmente due e possono essere svolte prima di introdurre una nuova modifica o dopo la sua introduzione. Nel primo caso si tratterà di preparare il codice per ospitare nuove funzionalità andando a migliorare il design dell’applicazione dove possibile al fine di rendere meno vincolanti alcune operazioni presenti nel codice già scritto. In questo modo si potrà risparmiare tempo nel momento in cui si renderà necessaria l’implementazione di nuove funzioni. Nel secondo caso, forse quello più comune, si lavora sul codice presente al fine di migliorarne la sua strutturazione immediatamente dopo aver aggiunto una nuova funzionalità. In questo modo il codice sarà lasciato sempre nella migliore delle condizioni per poterci lavorare in seguito. Le fasi di sviluppo saranno quindi due: inizialmente ci si concentra sul raggiungimento dell’obiettivo della funzionalità per poi passare al refactoring per ristrutturare e riorganizzare quanto appena prodotto.

Di pari passo con il refactoring va il testing che deve accompagnare l’implementazione in tutto il suo processo al fine di evitare spiacevoli sorprese al momento della messa in produzione della nuova funzionalità. Quando si applicano delle modifiche al codice sorgente è possibile che si inseriscano degli errori nel codice. Spesso capita che una modifica in un punto generi un errore in un’altra parte del programma come abbiamo visto quando abbiamo parlato di PHPUnit. Ogni volta che aggiungete una funzione scrivete subito un piccolo test che controlli il suo funzionamento, poi sviluppate la funzione ed eseguitelo. Se tutto va bene siete sicuri che il codice inserito funziona e che la modifica di questo non ha influito in modo distruttivo sul resto del codice. Quando applicate refactoring del codice eseguite spesso questi test; questo vi assicura che l’interfaccia del software sia sempre la stessa, e che tutto funzioni correttamente.

Alcuni link consigliati:

• Il sito di Martin Fowler sul Refactoring
• Refactoring: Improving the Design of Existing Code
• Code refactoring