L’apostata del TDD

Ho seguito con molto interesse la discusione generata da un post che vuole essere iconoclasta già nel titolo: l'apostata del TDD. Vorrei sottoporvi le mie annotazioni.

Perché il post mi pare interessante

Perché il post mi pare interessante? Perché tocca le corde della mia esperienza personale: anche io, come l'autore, ho provato curiosità nel notare di aver sviluppato a volte del buon codice senza l'uso del TDD e del pessimo codice con il TDD. Posto che è plausibile che problema risieda in me e non nel metodo, mi pare lecito comunque chiedersi se anche il metodo stesso non abbia qualche pecca. Provo infatti un certo fastidio quando, durante l'analisi di fallimenti del TDD (e mi pare che comunque ve ne siano), si escluda dogmaticamente che lo strumento possa avere qualche difetto. Tutto questo mi ricorda le critiche che (inutilmente) qualcuno negli anni 70 muoveva a psicanalisi e marxismo: ci si chiedeva infatti se fosse possibile che queste dottrine fossero di per sè corrette, mentre ogni loro clamorosa debacle si dovesse addebitare sempre ad una loro incorretta realizzazione, pienamente giustificabile ed interpretabile all'interno delle dottrine stesse.

Cosa non funziona nel TDD?

Ma allora cosa ci sarebbe di sbagliato nel TDD? Non so se vi sia qualcosa di "sbagliato", sicuramente indagherei su questi punti.

La visione d'insieme

Riprendendo quanto detto da Carlo Bottiglieri sulla lista extremeprogramming-it, il TDD potrebbe far perdere la visione d'insieme del problema, o anche problematiche trasversali all'intero sistema.

Cicli troppo stretti

Il TDD si basa sul "mantra" "red-green-refactor", che però, nella sua definizione, prevede di essere un ciclo di breve durata, per consentire un riscontro immediato. Ciò a mio avviso implica che la fase di refactor non possa spostare di molto l'"inerzia" del sistema: ciclo breve, refactoring breve, quindi spesso indirizzato a piccoli obiettivi. Il refactoring, inoltre, nascendo come "cura" per le puzze del codice, a risulta uno strumento di ottimizzazione locale: diminuisco la lunghezza dei metodi ed il numero di parametri, creo classi disaccoppiate, ottimizzo gli indicatori "locali" di qualità, ma la struttura generale è comprensibile e riutilizzabile?

Coesione vs accoppiamento

Durante un suo corso, Francesco Cirillo mi ha fatto riflettere su questo concetto: del buon codice deve essere ad alta coesione e a basso accoppiamento, ma vi è una tensione tra i due aspetti. Il mio dubbio è: il TDD tende a sistemi a basso accoppiamento, ma forse anche a bassa coesione?

No Big Upfront Design?

Il TDD ha viaggiato a braccetto con il concetto di "No Big Upfront Design", anche nella sua variante "non facciamo design prima di scrivere il codice, ma solo scrivendolo". Ma siamo proprio sicuri che il codice sia il l'unco luogo, o comunque quello ideale, dove disegnare il codice stesso?

Il lato oscuro dei test

Non dobbiamo dimenticare quello che Matteo Vaccari chiama "il lato oscuro dei test": paradossalmente un sistema copero al 100% da test potrebbe invitarci a scrivere codice "peggiore", in quanto, qualsiasi schifezza volessimo introdurre, avremmo sempre la certezza di non rompere nulla.

Sono anch'io un apostata?

Non so se dirmi apostata anch'io: forse non posso, non essendo mai stato un fedele praticante. ;-)
Sicuramente diffido di chi ha fatto del TDD una religione, o meglio un feticcio.
Forse, riprendendo la bella analogia di Jacopo Romei, sono nella fase "Ha – Vìola la regola" del ciclo "Shu-Ha-Ri": sto cercando di mettermi in opposizione al TDD, al fine di capirlo meglio.
Certamente vorrei saper usare il TDD come Carlo, ma a volte mi chiedo se questo non sia un tipo di programmazione che solo dei grandi virtuosi sono in grado di svolgere.
O forse sto ancora ricercando la mia via e sono ancora molto lontano anche dalla fase "Shu"...

Lascia un commento

You must be logged in to post a comment.