Posts
83
Comments
165
Trackbacks
11
TDD e lo sviluppo per approssimazioni successive

Non molto tempo fa, discutendo con Emanuele di alcune problematiche relative ad un progetto che stavo (e che sto tutt'ora) seguendo e alle possibili soluzioni da adottare, a fronte di alcune mie "pippe mentali" (come da lui stesso definite ), mi sospinse/indirizzò verso TDD...
Un rapido giro per la rete alla ricerca di alcune superficiali informazioni, giusto per inquadrare l'argomento e capire come e quando poterlo utilizzare nello sviluppo delle mie applicazioni e...boom!!! Ormai la mia mente si era/è messa in moto in modo da assimilare il più in fretta possibile queste nuove nozioni per comprenderne l'essenza e rendere tanta buona teoria molto produttiva. Devo essere sincero, all'inizio mi sembrava di avere a che fare con una di quelle "solite teorie"...molto teoriche  e poco pratiche, ma vi posso assicurare che con il passare dei giorni nella mia testa andava radicandosi la forte convinzione di aver "trovato" uno strumento/metodologia che poteva rendere più produttiva la mia fase di sviluppo.
Parallelamente a queste convinzioni mi sembrava di scorgere un'analogia lontana con qualcosa di conosciuto, ma non mi era ancora chiaro cos'era...solamente in questi giorni di ferie , nei quali ho potuto soffermarmi più approfonditamente su alcuni aspetti, mi sono accorto che TDD altro non è (non solo a dir la verità...) che la trasposizione nel mondo dello sviluppo software del metodo delle approssimazioni successive (utilizzato/adattato in vari ambiti tra cui la matematica, l'elettronica...).
Se non ricordo male , la soluzione di molti sistemi non lineari fonda le sue "fondamenta" su questo metodo interattivo per la ricerca della "soluzione ottima": partendo da un punto, a seguito (appunto) di approssimazioni successive, ci si avvicina sempre più alla soluzione che, nel contesto in esame, può essere ritenuta ottima.
TDD non "fa altro" che a fronte di una serie più o meno lunga di "sessioni di refactoring" far convergere la nostra applicazione verso una soluzione che si può ritenere ottimale. Starò sicuramente scoprendo l'acqua calda , ma vi posso assicurare che questa illuminazione è stata veramente...illuminante  e ha dato origine ad una serie di mie personali considerazioni inerenti ad un argomento a me/noi tanto caro: lo sviluppo di buone applicazioni... !!! Molte volte, ricercando questa soluzione ottima a priori, mi dilungavo su aspetti/tematiche che ritenevo indispensabili per rendere l'applicazione più flessibile, più robusta...abbassando a monte la mia produttività e allungando i tempi di sviluppo!
TDD, come più volte ho sentito dire nell'ambito delle metodologie agili, fa invece "emergere l'architettura" dell'applicazione a poco a poco...ma qui sta il punto focale: per rendere veramente agile lo sviluppo di un'applicazione tramite TDD deve esserci una considerevole dose di esperienza, è proprio questo, secondo me (e aggiungerei...come al solito ) l'ago della bilancia. E' l'esperienza che ci permette di partire da un punto già "prossimo" alla soluzione ottimale, riducendo il numero di "approssimazioni" (leggi sessioni di refactoring) da eseguire ed è sempre l'esperienza che ci deve far capire dove fermare la ricerca della soluzione ottima...

E con questo? direte voi ...
Bhe non ci deve essere un perchè per tutto, no?...

...sovvertiamo le gerarchie...
powered by IMHO 1.3
posted on martedì 2 gennaio 2007 17:22 Print