Ho sperimentato empiricamente sui progetto in cui ho lavorato che l'attività di design incrementale procede ad una velocità incostante.
Ci sono feature che riesco ad implementare velocemente e di cui sono soddisfatto del design ottenuto, mentre ce ne sono altre in cui faccio molta fatica per implementarle e con poca soddisfazione del risultato.
Kent Beck suggerisce di rallentare quando si verificano queste situazioni di attrito. Rallentare significa procedere per passi sempre più piccoli fino a riuscire a superare l'ostacolo.
Uno dei vantaggi del TDD è proprio quello di poter controllare la velocità: mi sento confidente? Vado veloce. Mi sento poco confidente? Rallento.
Quando mi trovo in queste situazioni un'altra tecnica che trovo efficace è quella di risolvere il problema in almeno due modi diversi. Sembra una perdita di tempo in realtà aumenta notevolmente la conoscenza del sistema e spesso evidenzia limiti del design che altrimenti non si noterebbero e che farebbero perdere molto più tempo in seguito.
Bisogna avere coraggio: se perdo confidenza nell'implementazione attuale è meglio fare revert e rifare la feature su cui si sta lavorando altrimenti si rischia di aumentare eccessivamente la complessità del sistema e di introdurre dei difetti.
Un'altra tecnica molto utile consiste nello spiegare cosa si sta facendo e quali problemi sto incontrando ad un altro membro del team; oppure, se la soluzione è sufficientemente generica, scrivere un articolo od un post sul proprio blog.
Trovo utile, banalmente, alzarmi dalla sedia fare quattro passi e ritornare a lavorare questo a volte porta ad una buona intuizione che semplifica il design e lo rende più malleabile.
E a voi vi capitano questi blocchi? Cosa fate per risolverli?