In questi giorni (a dir la verità oramai sono un po’ di settimane…ma il mio tempo di risposta si sta facendo un po’ troppo lungo :-( ), sulla ML di ugialt.net è in corso una discussione sul perchè la pratica del TDD sia poco diffusa nelle aziende italiane e sul perchè sia così difficile farla adottare.
Oltre alle solite motivazioni riconducibili al “qui in Italia siamo sempre N anni indietro”, volevo provare a guardare la situazione da un altro punto di vista, quello delle aziende, portando la mia “esperienza” come consulente in alcune di queste aziende.
Bisogna partire, secondo me, dal concetto che “fare TDD” solo perchè fa figo, senza capirne vantaggi e svantaggi è solo deleterio: ci si trova con tonnellate di codice (test + produzione) da manutenere, il tempo a disposizione si riduce e quindi si accelerano i “battiti” e la prima cosa che si taglia sono i test…ecco avere un progetto testato a metà è peggio che non averlo testato per nulla: si ha una effimera sicurezza dettata dai test parziali che si rivela estremamente controproducente.
Sviluppare applicazioni utilizzando come pratica il “farsi guidare dai test” non è affatto facile, la rampa di apprendimento iniziale è abbastanza ripida e molte aziende identificano in questa iniziali difficoltà il fatto che i tempi di sviluppo si dilatano esponenzialmente. Non è assolutamente facile, soprattutto all’inizio, ma anche dopo parecchia pratica, scrivere test veramente unitari e codice fortemente disaccoppiato per rendere il tutto facilmente testabile.
Ma perchè introdurre tutte queste interfacce, quando con un’unica classe e un paio di metodi riesco ad ottenere lo stesso risultato? Questa è la domanda che sempre più frequentemente mi viene posta e sinceramente, oltre alla mia risposta “puramente teorica” (codice più testabile, fortemente disaccoppiato e quindi riutilizzabile e sostituibile…), quando si tocca il discorso tempistiche di rilascio, faccio fatica a controbattere.
La pratica del TDD è una metodologia di sviluppo software che va appresa con il tempo, con la pratica e sopprattutto con tanti sacrifici…non è assolutamente facile e immediata, ma non per questo alle prime difficoltà si deve abbandonare: i benefici, nel medio/lungo periodo, sono sicuramente superiori ai disagi (e ritardi) iniziali. Nel mondo reale, non sempre (quasi mai?!?!?) le aziende, e quindi i loro team di sviluppo, hanno la possibilità di investire tempo e risorse per poter fronteggiare le difficoltà iniziali…è proprio in questo periodo iniziale che come consulente “praticante” (del TDD) *devo* essere più vicino a questi team per farli sentire più sicuri (in futuro ci penseranno i test), per non farli barcollare alle prime difficoltà e non demordere nel vedere i tempi dilatarsi (entro un limite ragionevole ovviamente) e soprattutto devo essere più chiaro e convincente nello spiegarne i benefici.
Alla prossima
-melkio-