Da almeno due anni il mio approccio allo sviluppo è fondamentalmente cambiato…per fortuna aggiungerei, ma questo è un altro discorso ;-)
Lo stravolgimento maggiore, sotto tutti i punti di vista, è sicuramente stato dettato dall’adozione del TDD come metodologia di sviluppo.
Parlando con alcuni clienti e con alcuni amici “del mestiere”, mi sono accorto che l’efficacia del TDD e i benefici che ne conseguono dalla sua adozione non sono per tutti così evidenti. In effetti, ora che ci penso, anche io quando ne ho sentito parlare per la prima volta non ne sono stato convinto appieno. Ecco quindi la necessità/desiderio di portare la mia esperienza per “formalizzare” quelli che per me sono stati (e sono tutt’ora) i benefici maggiori che ho riscontrato “strada facendo”
Partiamo dal presupposto che, come tutte le cose nuove, l’adozione del TDD come metodologia di sviluppo ha un costo in termini di acquisizione delle nozioni di base e sopprattutto dell’attualizzazione e della messa in opera di tali concetti nella realtà. Detto questo voglio rimarcare un punto fondamentale: il TDD non è un costo!!!
Affermare che la scrittura del solo codice “produttivo” (non dico di produzione, perchè per me i test lo sono) costa meno che la scrittura incrementale di test e codice insieme è assolutamente errato e sono pronto a provare il contrario.
Sperando che questa sia la posizione condivisa da tutti…proseguiamo.
Come primo vantaggio, basilare, che l’adozione del TDD come metodologia di sviluppo è proprio la possibilità di avere sempre, in tempo reale, il nostro codice allineato con una (più o meno) ampia batteria di test. Demandare a “sviluppo” terminato la scrittura del codice di test è per me un costo, talvolta anche inutile e soprattutto un’utopia.
La mia batteria di test mi garantisce, in ogni momento del ciclo di vita dello sviluppo del mio progetto, di poter sostenere modifiche, anche importanti, ai comportamenti definiti in partenza, con una ragionevole sicurezza di non avere errori di regressione su funzionalità ormai consolidate.
Un altro aspetto è l’approccio allo sviluppo che il TDD ti “impone”: l’avanzare per piccoli passi imposta un ritmo che evita il proliferare di “generalizzazioni accessorie e derive intellettuali” tipiche (almeno per me) dello sviluppo tradizionale. Molte volte mi sono trovato a sovra-ingegnerizzare una soluzione perchè non avevo nulla che frenasse la mia “furia” inventiva.
Attenzione bene: non sto dicendo che con l’approccio “tradizionale” non sia possibile confinare e ritmare correttamente lo sviluppo, sto solo affermando, con ragionevole certezza, che il TDD ti aiuta a concentrarti solo sull’aspetto implementativo, senza demandare allo sviluppatore la preoccupazione di “contenersi”. Insomma un validissimo aiuto.
Ma l’aspetto preponderante, che mi fa consigliare e spingere sempre di più questo approccio ai miei clienti, è sicuramente la qualità del codice che si riesce ad ottenere in modo del tutto naturale. Il TDD impone (involontariamente, ed è per questo che è naturale) una forte attenzione al design della nostra applicazione.
Per fare in modo che ogni componente del nostro eco-sistema sia facilmente testabile singolarmente e in relazione agli altri (cosa a cui il TDD ambisce) otteniamo con assoluta naturalezza un codice “semplice e pulito”, facilmente manutenibile e soprattutto che soddisfa parecchi paradigmi della programmazione OO (e della buona programmazione, aggiungerei).
Giusto per puntualizzare e evitare possibili flame, voglio sottolineare che TDD non significa non avere bug nelle proprie applicazioni. Nella mia esperienza lo sviluppo in TDD ha significato (e significa tutt’ora) una forte diminuzione dei bug “scappati al mio controllo”, rilasciati in produzione e soprattutto una velocità di risposta alla segnalazione delle anomalie senza paragoni.
Che ne pensate? Qual è la vostra esperienza a riguardo?
-melkio-