|
Ho letto il libro di Beck sul TDD...ed ho appena iniziato Refactoring di Fowler...
Posso quindi esprimere un mio giudizio sul TDD...ovviamente non è derivato da studi teorici, ma solo dall'esperienza pratica...
Prendi il caso di Diamonds... Siamo un team non omogeneo, sia dal punto di vista culturale informatico, che dal punto di vista dell'esperienza...
Sicuramente è più facile scrivere test che scrivere una soluzione che funziona al primo colpo per un problema...su questo penso che non ci siano dubbi...
Il test stesso ti obbliga ad entrare nella mentalità della soluzione... Magari prima di scrivere il test pensavi di risolvere il tuo problema in tutt'altro modo... Ma sai che devi scrivere il codice più semplice che funziona per rendere al più presto possibile verde il test...e vai a testa bassa a scrivere il codice che fa passare il test...
Si eliminano le eventuali duplicazioni e si va al prossimo test...
Ecco che abbiamo completato una parte del nostro task....e questo praticamente senza margine di errore (o almeno il margine dipende da quanto i test coprono il dominio degli ingressi e le sequenze di chiamata)... Il TDD tende ad indirizzare le persone che scrivono il codice verso una determinata soluzione...
Prendi 10 persone e proponi in sequenza i test....vedrai che 8 su 10 arriveranno alla medesima soluzione...
I test guidano il programmatore a scrivere la soluzione che la sequenza di test vuole imporre...
Ed ecco che hai uniformato un team di sviluppo non omogeneo...ed allora mi dirai: cosa studaimo a fare ?
I refactoring sono la via cruciale di un codice funzionale e manutenibile... Le conoscenze, le esperienze e, perchè no, la genialità di ognuno di noi vengono fuori proprio nei momenti di refactoring...
Se il TDD è il conformismo che spinge tutti ad una soluzione comune, il refactoring è il suo alter ego geniale...l'intuito o l'esperienza che ti guida verso una forma già vista o inventata su due piedi...ma sempre con i test che mettono dei paletti che non puoi prevaricare...
|