"The debugger isn't a substitute for good thinking. But in some case, thinking isn't a substitute for a good debugger either. The most effective combination is good thinking and a good debugger"
Steve McConnell, nel suo Code complete, fornisce una lauta Checklist a proposito del debugging.
Tra le tante voci vale la pena citare:
- Exercise the code in your test suite
- Reproduce the error several different ways
- Use the result of negative tests
- Keep a notepad by your desk, and make a list of things to try
Con questi piccoli accorgimenti sarà possibile fare bug fixing, qualora fosse indispensabile e il TDD non faccia luce sul problema, molto più velocemente. La velocità però non deve essere il principale fattore guida, troppa fretta porta altri bug rinchiudendo la fase di debugging in un circolo vizioso. Infatti la checklist continua con un "relax", questo è un buon consiglio. Se manca tempo, o il debugging porta al malditesta, prendere cinque minuti (o dieci) possono portare un vantaggio consistente nel lungo periodo.
Solo su una voce della lista non sono pienamente d'accordo: "Change the code only for good reason". E' vero, non devo fare sciocchezze nel codice, ma essere coraggiosi e apportare cambiamenti sostanziali al design può essere più che produttivo, e far ciò mi è facilitato se ho sviluppato tramite Test dato che in ogni momento che apporto una modifica al codice sarò certo se questo funzionerà correttamente o meno.
Un buon inizio per capire come fare red-green refactor o il TDD è wikipedia, o questo articolo su agiledata.
Nessun commento:
Posta un commento