L’importanza della semplicità nel design applicativo

Il design del software è il processo di organizzazione delle sezioni del codice attraverso le sue funzioni, oggetti, metodi e strutture dati, l’architettura generale del sistema e l’interazione tra le sue componenti.

Le scelte operate sull’architettura del software condizionano l’efficienza con la quale è possibile soddisfare le richieste dei clienti in merito all’introduzione ed alla modifica delle funzionalità.

Operare le scelte corrette al principio di un progetto ma, soprattutto, mantenere una buona architettura nel tempo significa prestare attenzione a che il software non presenti componenti superflue o duplicate e rimanga intellegibile alla community di sviluppatori.

È evidente che oggi, con il ricorso alle metodologie iterative ed incrementali di sviluppo previste dall’Extreme Programming¹ (XP) con cicli Test-Driven Development² (TDD), si tende a non progettare un intero sistema dal green field. Piuttosto, in accordo da quanto previsto dai metodi Agile³, si ordinano per valore le richieste del cliente sviluppando prima gli elementi più importanti e, solo successivamente, quelli meno importanti.

È evidente che tale modalità può comportare la riscrittura di componenti del software, ciò è insito nell’approccio Agile, ma non bisogna mai perdere di vista il principio secondo il quale il livello di rivisitazione e la complessità del disegno devono rimanere adeguati al problema da risolvere. Diversamente ho potuto osservare rapide derive in termini di tempi e budget di progetto.

Di semplicità nel design applicativo si sono occupati diversi autori, da Kent Beck⁴ a Martin Fowler⁵ a Robert Martin⁶ a Corey Haines, ma le regole definite sono essenzialmente quattro. Appare evidente che nella realtà non tutte sono applicabili per ogni contesto, ma anche un subset di esse è un contributo alla causa dell’Extreme Programming!

1. Passare tutti i test

La prima regola consiste, in ogni momento, nel soddisfare i test sul codice prima di ogni refactoring. Se il codice non supera i test, sarà anche difficile individuare eventuali bug. In qualunque stadio si trovi il codice, questo deve funzionare. Questa regola mira a garantire la produzione del valore necessario al cliente.

2. Esprimere lo scopo del programmatore

Un frammento di codice dovrebbe immediatamente dire cosa fa e non dovrebbe lasciar spazio a sorprese. I nomi di variabili, dei metodi, delle classi, pacchetti, servizi, funzioni, configurazione, sistema di test ed in generale tutte le componenti del software dovrebbero descrivere ciò che fanno attraverso una nomenclatura comprensibile al momento della loro scrittura e in futuro.

Dobbiamo produrre codice sorgente oggi considerando sempre la possibilità di intervenirvi successivamente, anche dopo diversi anni, quando la memoria storica in azienda magari non ci sarà più. Il codice deve parlare da solo.

3. Non contenere duplicazioni

La terza regola ha a che fare con la rimozione della duplicazione delle parti. Più componenti del software che fanno la stessa cosa hanno un costo di manutenzione ordinaria ed evolutiva ingiustificato. Il fenomeno si verifica spesso in presenza di progetti molto vasti che coinvolgono una moltitudine di professionisti nello sviluppo. È allora il refactoring il momento in cui, con l’ausilio dei test, componenti sovrapponibili del codice vengono assimilati.

In generale, nello sviluppo del software, ci si riferisce al principio noto come DRY⁷ (Don’t Repeat Yourself) per indicare la riduzione delle duplicazioni in senso lato, riferibili cioè anche all’architettura dell’intera soluzione.

4. Minimizzare il numero di classi e metodi

La quarta ed ultima regola costituisce una mera ottimizzazione. L’applicazione, applicando il principio YAGNI⁸ (You Aren’t Gonna Need It), non dovrebbe includere codice di cui non c’è necessità cogente. La regola consiste nel rimuovere qualsiasi codice inutile resistendo all’impulso di progettare componenti per eventuali esigenze future di cui non si è sicuri.

Ex post, se l’applicazione contiene parti che all’epoca della realizzazione sembravano una buona idea, ma che non sono mai state realizzate, deve essere snellita.

A volte è difficile minimizzare correttamente quando si è concentrati sui dettagli, per questo motivo è bene fare, occasionalmente, un passo indietro e valutare il risultato.

¹ https://en.wikipedia.org/wiki/Extreme_programming 

² https://en.wikipedia.org/wiki/Test-driven_development 

³ https://en.wikipedia.org/wiki/Agile_software_development 

⁴ https://en.wikipedia.org/wiki/Kent_Beck 

⁵ https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer)

⁶ https://en.wikipedia.org/wiki/Robert_C._Martin

⁷ https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

⁸ https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Bibliografia:

• DevOps Guida per integrare Development e Operations e produrre software di, Fabio Mora
• Clean architecture. Guida per diventare abili progettisti di architetture software, Robert C. Martin
• Clean Code: Guida per diventare bravi artigiani nello sviluppo agile di software, Robert C. Martin
• L’arte del refactoring. Guida alle tecniche per migliorare il design e la leggibilità del codice, Martin Fowler
• Understanding the 4 Rules of Simple Design, Corey Haines