Nuova feature e impatto sul codice
Analizzando la codebase (implementazione e casi di test), Massimo fa notare che qualcosina è migliorabile. Introduciamo la feature ora, e cioè stampare Bang per tutti i numeri divisibili per 7. Ovviamente la feature non deve rompere l’attuale comportamento, per cui vanno tenuti in considerazione anche i seguenti casi:
- 3,7 -> FizzBang
- 5&7 -> BuzzBang
- 3&5&7 -> FizzBuzzBang
Gestire un ulteriore divisore ha un impatto sia sul codice che nei test, e si passerebbe da 3 ramificazioni, o meglio branch (istruzione if
nel codice), a 7. Verrebbe da pensare di aggiungere degli if per implementare la richiesta, ma cosa succederebbe se si decidesse di aggiungere un ulteriore divisore, ad esempio il numero 11? Si avrebbero ben 19 ramificazioni. Decisamente troppe.
Come agire quindi? Modifichiamo in base ai dati (data change) o al comportamento (behaviour change)?
E’ meglio fare prima refactor per preparare il campo alla nostra modifica, agendo a piccoli passi lasciandosi guidare dai test piuttosto che implementare prima la richiesta e poi eseguire il refactor.
E già che ci siamo, proviamo a implementare la modifica con una sola riga di codice, magari eliminando tutti i branch.