Design Semplice

XP ha un mantra: Fai la cosa più semplice che potrebbe funzionare.

Non si tratta di essere pigri o scrivere codice approssimativo. Il codice semplice è spesso più difficile da scrivere del codice complesso. Richiede:

• Comprendere il problema in profondità
• Resistere all'impulso di generalizzare
• Dire "no" alla speculazione
• Fidarsi del fatto che puoi cambiare le cose in seguito

Il codice semplice è:

• Facile da capire
• Facile da modificare
• Facile da testare
• Appena sufficiente per le esigenze attuali

Il codice complesso è:

• Difficile da capire
• Rischioso da modificare
• Difficile da testare
• Costruito per esigenze future immaginarie che potrebbero non arrivare mai

YAGNI è il principio secondo cui dovresti costruire solo ciò di cui hai bisogno adesso.

Non aggiungere:

• Funzionalità perché "potrebbero essere utili"
• Opzioni di configurazione perché gli utenti "potrebbero volerle"
• Punti di estensione perché il codice "potrebbe averne bisogno"
• Astrazioni per ipotetici requisiti futuri

Perché? Perché:

• Di solito ti sbagli su ciò di cui avrai bisogno
• Il codice inutilizzato ha comunque un costo di manutenzione
• Ogni astrazione ha un prezzo in termini di complessità
• Costruire per il futuro ritarda la consegna per oggi

La scommessa di XP: se avrai bisogno di qualcosa in seguito, potrai aggiungerla in seguito. Con TDD, refactoring e CI, il cambiamento costa poco. Quindi non pagare per il futuro prima di doverlo fare.

Questa è un'idea radicale. L'ingegneria del software tradizionale dice di anticipare il cambiamento e progettare per la flessibilità. XP dice di aspettare fino a quando non ne hai effettivamente bisogno.

Kent Beck ha definito il design semplice come codice che:

1. Supera tutti i test Il codice funziona. Questo non è negoziabile. Un design bellissimo che non funziona non vale nulla.

2. Rivela l'intenzione Il codice è facile da capire. Buoni nomi, struttura chiara, organizzazione leggibile. Qualcuno di nuovo può prenderlo e capire cosa fa.

3. Non ha duplicazioni (DRY) Ogni pezzo di conoscenza è espresso una volta e una sola volta. La duplicazione crea onere di manutenzione e rischio di bug.

4. Ha il minor numero di elementi Nessuna classe, metodo, variabile o astrazione extra. Tutto ciò che esiste ha una ragione per esistere.

Le regole sono in ordine di priorità. Superare i test prevale su tutto. Ma una volta che i test passano, favorisci la chiarezza rispetto al DRY. E aggiungi solo elementi che servono le prime tre regole.

Il design semplice non significa nessun design. Significa design incrementale—far evolvere il design man mano che impari.

Il processo:

1. Inizia con l'implementazione più semplice che funziona
2. Man mano che aggiungi funzionalità, nota gli attriti (sta diventando scomodo)
3. Fai refactoring per affrontare gli attriti
4. Il design emerge da esigenze reali, non da speculazioni

Ecco perché XP enfatizza così tanto il refactoring. Se non puoi cambiare il codice in sicurezza, non puoi fare design incrementale. Sei bloccato con qualunque cosa tu abbia costruito per prima.

Il Big Up-Front Design (BUFD) fallisce perché:

• Non sai abbastanza all'inizio
• I requisiti cambiano
• I design non sopravvivono al contatto con la realtà
• Paghi per la complessità che non usi mai

Il design incrementale ha successo perché:

• Progetti in base a esigenze reali
• Il design evolve con la comprensione
• Non paghi mai per ciò che non usi
• Il refactoring mantiene il design pulito

Il design semplice non significa evitare ogni complessità. A volte la complessità è necessaria.

Aggiungi complessità quando:

• I test la richiedono (fallo passare)
• La chiarezza la richiede (rivela l'intenzione)
• Rimuovere la duplicazione la richiede (DRY)
• I requisiti attuali e reali ne hanno bisogno

Non aggiungere complessità per:

• Scenari "e se?"
• Possibili funzionalità future
• Framework che pensi di poter aver bisogno
• Rendere il codice "più flessibile"

La differenza è tra complessità essenziale (intrinseca al problema) e complessità accidentale (introdotta dalla tua soluzione). XP minimizza la complessità accidentale rifiutandosi di costruire per requisiti immaginari.

Quando hai davvero bisogno di un'astrazione, lascia che emerga dalla rimozione della duplicazione. La "Regola del Tre" è utile: non astrarre finché non vedi lo stesso pattern tre volte. A quel punto capisci le variazioni effettive, non quelle immaginate.