Le 4 Regole del Simple Design

La Nascita delle 4 Regole del Simple Design

Negli anni ’90 Kent Beck ha descritto per la prima volta queste regole nel suo libro “Extreme Programming Explained” sull’onda di una discussione sul Wiki di Ward Cunninham. Molte altre persone hanno condiviso le loro esperienze nell’utilizzo di queste regole, tra cui Joe Rainsberger e Ron Jeffries, chiamandole “Le Regole di Kent Beck”. Nel 2014 Corey Haines ha pubblicato il libro “Understanding the 4 Rules of Simple Design” dove usa esempi per esplorare e spiegare le regole, riportandole di nuovo alla ribalta.

LE REGOLE

Un buon software deve soddisfare i seguenti requisiti (ordinati secondo “Understanding the 4 Rules of Simple Design” di Corey Haines):

1. Passare tutti i test
2. Esprimere lo scopo del programmatore
3. Non contenere duplicazioni
4. Minimizzare il numero di classi e metodi

PASSARE TUTTI I TEST

Se non riesci a dimostrare che il tuo progetto funziona e fa quello che deve fare, che importanza può avere se è semplice o complesso? Se non supera i test, sarà anche difficile individuare eventuali bug.

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 e delle classi dovrebbero descrivere ciò che fanno (“the principle of least astonishment” o “the element of least surprise”).

NON CONTENERE DUPLICAZIONI

Un buon progetto non dovrebbe contenere alcuna duplicazione, principio noto anche come “Don’t Repeat Yourself” (DRY). Questo non significa solo duplicazione del codice in senso letterale, ci riferiamo anche alla duplicazione dell’implementazione delle regole di business; dobbiamo evitare di implementare in posti diversi ed in modi diversi lo stesso requisito funzionale. Le logiche con cui vengono ottenute determinate informazioni devono inoltre essere definite in un punto determinato e ben individuabile, in modo da essere facilmente rintracciabili e manutenibili.

MINIMIZZARE IL NUMERO DI CLASSI E METODI

L’applicazione non dovrebbe includere codice di cui non avete bisogno. Rimuovete qualsiasi codice inutile, resistete alla voglia di progettare per eventuali esigenze future di cui non si è sicuri. L’applicazione contiene parti che all’epoca 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.

La fonte in lingua inglese per questa #pilloladiinformatica è questo articolo di Nicole Bekkers:
https://www.theguild.nl/4-rules-of-simple-design/