Sempre più spesso il codice ha un cattivo odore.

Sei sicuro di non scrivere codice puzzolente? Vediamo come riconoscere quali sono le code smell più frequenti e quali metodologie utilizzare per minimizzarle.

Spesso, durante la progettazione di una nuova architettura si cerca di renderla molto flessibile con il fine di minimizzare gli sforzi necessari per apportare nuove feature in futuro. Questo tipo di approccio sembra essere molto sensato, ma non lo è nella realtà. Troppo spesso le nostre previsioni sulle eventuali evolutive sono errate, con la ovvia conseguenza di aver sprecato tempo, aver prodotto un over-design e reso il codice scritto eccessivamente ed inutilmente complesso. Inoltre tutto il codice prodotto inutilmente non verrà mai rimosso e continuerà a condizionare gli sviluppi futuri.

L’over-design produce due ulteriori effetti collaterali, il primo consiste nel richiedere un maggiore tempo di sviluppo per adeguarsi all’architettura sofisticata, il secondo consiste nella duplicazione di codice che molti sviluppatori, specie se poco esperti, tendono a fare per non perdere il tempo necessario alla comprensione dell’architettura in essere, essendo quest’ ultima eccessivamente sofisticata.

E’ altresì frequente, durante la progettazione di una nuova architettura, ragionare solo sul presente senza considerare eventuali evolutive future. Questo approccio è dettato principalmente dal contenimento dei costi di realizzazione, ma produce effetti collaterali non meno pericolosi dell’over-design. In particolare si avranno sicuramente maggiori costi in futuro a causa di quelli che in gergo vengono chiamati debiti di sviluppo e come ogni debito deve essere estinto velocemente per non esserne sommerso. Purtroppo il debito viene estinto raramente, trovandosi così a estendere codice complesso, dove nessuno osa modificare più del necessario.
Per nostra fortuna esiste una soluzione intermedia agli scenari sopra esposti: Test Driven Development e Continuos Refactoring. Queste due metodologie sono due anelli portanti della XP programming In altre parole ogni qualvolta si debba progettare una nuova architettura o modificare quella esistente si dovrà disegnare una soluzione calzante per il requisito attuale, senza inutili previsioni future, ma nemmeno senza trascurare i più semplici criteri di estendibilità e scalabilità del sistema. All’inizio di ogni fase di sviluppo si dovranno scrivere tutti i test automatici necessari alla validazione del codice che si andrà a scrivere successivamente.

I test automatici scritti sono certamente un costo iniziale non trascurabile, ma questo costo è facilmente assorbibile, se non immediatamente nel presente, certamente nella fase di bug fix e nelle evolutive future. I test automatici scritti prima di iniziare la fase di sviluppo portano i seguenti benefici:

1. Miglior comprensione della funzionalità richiesta (meno bug meno costi);
2. Test automatici utilizzabili in fase di sviluppo e nella successiva fase di bug-fixing: ogni fix apportato non rischia di rompere il pregresso (fix più veloci e mirati, quindi meno costi);
3. Facilitano la fase di continuo refactoring, in quanto non si ha il timore di rompere il pregresso. Il continuos refactoring mantiene l’architettura continuamente aggiornata eliminando le inutili complessità

Grazie all’approccio della Test Driver Programming e Continuos Refactoring sarà più facile mantenere un codice più semplice e più manuntenibile.

Vediamo ora un elenco delle code smells più frequenti, riservandomi in un prossimo articolo un approfondimento maggiore delle stesse.

1. Codice duplicato, questo è uno degli odori più pungenti che possiamo trovare nel codice. Spesso è causato da una scarsa comprensione dell’ as-is che porta a riscrivere ciò che esiste già. La manutenzione sul codice duplicato ha costi elevatissimi.
2. Costrutti condizionali complessi, ovvero costrutti condizionali chilometrici frutto di una stratificazione del codice. Intervenire su un if-then-else complessi  introduce numerosi regression bugs.
3. Metodi troppo lunghi, un metodo dovrebbe eseguire un operazione elementare, c’è chi sostiene che non dovrebbe essere più lungo di una decina di linee di codice. Ne ho visti contenenti diecimila righe di codice!
4. Metodi con troppi parametri, se il metodo è breve probabilmente ha bisogno di pochi parametri in ingresso, ma se un metodo è enorme anche la sua signature lo sarà inesorabilmente. Un numero eccessivo di parametri rende la funzione del metodo incomprensibile e troppo generica. Chi necessita di una sotto funzionalità del metodo sarà costretto a duplicarne una parte. E si ritorna al primo punto!

Queste elencati sono le peggiori code smells ma ne esistono altre meno frequenti. Non dobbiamo temerle al loro nascere, ma vanno eliminate al più presto con il refactoring.