A refactoring example in java

Siamo in retrospettiva, il team discute di come poter migliorare il proprio lavoro e qualcuno propone: “Perché non iniziamo a refattorizzare il codice che modifichiamo?”
Purtroppo, spesso la risposta è: “Sarebbe bello farlo, ma non abbiamo tempo”.

Come mai il refactoring è un’abitudine così difficile da acquisire? Quali sono le maggiori restistenze e su quali leve possiamo giocare per introdurlo? Proveremo a darvi qualche spunto che aiuti a rispondere, almeno parzialmente a queste domane. Ma partiamo dal principio.

Nel panorama dello sviluppo software, il refactoring si presenta come una disciplina essenziale per plasmare il codice in modo elegante, efficace e sostenibile nel tempo.

Il refactoring è il processo di ristrutturazione del codice senza cambiarne il comportamento. È come cambiare l’arredamento della casa mettendo mobili più moderni, funzionali e belli esteticamente. La casa continua ad essere sostanzialmente la stessa, ma avrà un mobilio più piacevole da vedere e più comodo da usare. Allo stesso modo, fare refactoring significa apportare modifiche al codice per migliorarne la leggibilità, la manutenibilità o le prestazioni, mantenendo intatto il comportamento dell’applicazione e consentendo una crescita organica del software nel tempo.

I principi guida

Il segreti per un buon refactoring sono pochi, ma cruciali per evitare di cadere in un tunnel di modifiche a cascata che rischia di impiegare le nostre giornate a risolvere problemi di compilazione e regressioni.

  1. Conservare il Comportamento: Durante il refactoring, è essenziale mantenere inalterato il comportamento del software. Qualsiasi modifica apportata al codice dovrebbe essere trasparente agli utenti e alle altre parti del sistema. La modifica ad una firma di un’interfaccia o a qualsiasi oggetto eposto significa cambiare il comportamento del sistema e andrebbe gestito come una nuova implementazione, non come refactoring.
  2. Piccoli Passi Incrementali: Refattorizzare è un processo graduale. È più efficace suddividere le modifiche in piccoli passi incrementali, garantendo che ogni passo sia sicuro e reversibile. Questo permette di mantenere il software funzionante durante il processo di ristrutturazione, specialmente quando si intraprendere un refactoring su una porzione di codice (ad esempio una classe) particolarmente sostanziosa.
  3. Testare Rigorosamente: L’uso di test automatizzati è fondamentale nel refactoring. I test assicurano che le modifiche apportate al codice non introducano nuovi bug e che il comportamento atteso sia sempre garantito. La regola d’oro quando si fa refactoring è quella di non modificare i test esistenti, in quanto la necessità di una modifica dei test è indice di una modifica al comportamento del sistema, che quindi andrebbe evitato. È invece consigliato aggiungere nuovi test, qualora ci accorgessimo che alcuni punti del codice non sono coperti a dovere.

Testare l’intestabile

Un ostacolo che spesso si insinua tra gli sviluppatori e l’introduzione del refactoring, è il timore del cambiamento al codice esistente. La paura di introdurre errori, rallentare lo sviluppo o destabilizzare il sistema può paralizzare l’adozione dei miglioramenti necessari.

In realtà, il refactoring può essere proprio un prezioso alleato in queste situazioni garantendoci diversi vantaggi che ci consentono di modificare il codice esistente in sicurezza:

  • Introducendo dei piccoli refactoring e grazie al supporto dei test automatici, gli sviluppatori possono acquisire familiarità con il codice esistente e sviluppare la confidenza necessaria per affrontare il cambiamento senza timori eccessivi.
  • Il refactoring permette di rendere il codice più manutenibile e gestire le modifiche in piccoli incrementi rendendo il cambiamento meno intimidatorio. Gli sviluppatori possono concentrarsi su modifiche specifiche, testarle accuratamente e implementarle in modo sicuro senza dover affrontare il peso di modifiche radicali.
  • Dove necessario, l’aggiunta di test automatici permette di creare una rete di sicurezza che abbassa il rischio di regressioni e mal funzionamenti potenzialmente introdotti dalle modifiche effettuate al codice esistente
  • Il refactoring effettuato renderà il codice più menutenibile ed evolvibile in caso di modifiche successive in futuro.

Refactoring, quanto mi costi?

Un’altra fonte di resistenza altrettanto frequente quando si introduce il refactoring, è la percezione di “perdita di tempo” e rallentamento degli sviluppi.
È comprensibile la reticenza di chi non è abituato a refattorizzare il proprio codice, e in effetti il refactoring va curato ed applicato costantemente durante tutto lo sviluppo, con la stessa importanza con la quale si scrive il codice di produzione o si aggiungono i test automatici.

Ma d’altro canto, sarebbe accettabile che un chirurgo non si lavasse le mani prima e dopo un’opeazione perché “non ha tempo?” L’analogia potrebbe sembrare audace, ma riflette la sua essenzialità come pratica quotidiana. I chirurghi non discutono sull’importanza di lavarsi le mani prima e dopo un’operazione; è parte integrante della loro deontologia professionale. Allo stesso modo, gli sviluppatori dovrebbero abbracciare il refactoring come una routine che contribuisce al benessere del codice.

Inizialmente, il refactoring può apparire come un costo aggiuntivo in termini di tempo e risorse nel breve termine, ma diventa un importante investimento nel medio-lungo periodo agendo come una sorta di assicurazione contro il disordine del codice. In un contesto di sviluppo continuo, la manutenzione del software è inevitabile e investire tempo nel refactoring riduce la sua complessità e facilita la gestione delle successive modifiche.

Un codice ben rifattorizzato è più sicuro, l’introduzione di nuove funzionalità o modifiche diventa meno rischiosa e si riduce il rischio di bug e regressioni. Ciò si traduce in un risparmio considerevole di tempo e budget quando arriva il momento di aggiornare, estendere o correggere il software.

Il refactoring nella cultura organizzativa

È importante integrare il refactoring come parte della cultura organizzativa.
Invece di considerarlo come un’attività separata, deve essere parte integrante del processo di sviluppo quotidiano, un contributo alla salute a lungo termine del software, non un’attività isolata e onerosa.
Per raggiungere questo stato ideale, è fondamentale che l’area tecnica aiuti a far emergere l’importanza di queste pratiche alle persone non tecniche che si occupano di business, esplicitando come un refactoring continuo aiuti a mantenere bassi i costi e le difettosità introdotte, tutto a beneficio della soddisfazione dei clienti e del business aziendale.

 

Costruisci il tuo percorso verso l’eccellenza tecnica