oggi a pranzo con qualche collega discutevamo di come risolvere un esercizio di logica (ad esempio, trovare l'intersezione tra array, e valutarne la complessità), che il nostro coach ognitanto ci lascia come stimolo per tenere allenata la mente, e per favorire il confronto tra tutti noi del team. io non ho ancora dato la mia di soluzione - non ci ho ancora lavorato - ma ho commentato dicendo qualcosa come "userei una qualche Collection, che di sicuro fornisce l'intersect". spiazzante, lo so. e sbagliato, dato che non è quello lo scopo di questo tipo di esercizi.
il fatto è che, come ho poi spiegato, non nutro una particolare passione per gli algoritmi, il loro confronto, la loro ottimizzazione. ho anche aggiunto che (e forse questa è la cosa più interessante) se non avessi scoperto l'ingegneria del software, probabilmente non sarei mai diventato uno sviluppatore. durante gli anni di università infatti, ho sempre odiato programmare. se non fosse per l'amore della progettazione del software, del suo ciclo di vita, delle architetture, del paradigma ad oggetti, della complessità associata, sicuramente non avrei mai scelto di fare questo mestiere.
pausa, e respiro.
qualche tempo fa, chiaccherando con un mio amico-quasi-collega che provava a lusingarmi per le mie doti di programmatore, mi sono trovato a rispondergli dicendo che si sbagliava, e che anzi di fatto doveva considerarmi "un designer a cui tocca programmare". ripensandoci, devo dire di aver proprio fatto centro - in vino veritas.
eppure, il mio lavoro quotidiano altro non è che scrivere codice. e lo adoro. com'è potuto accadere? in realtà non è difficile capirlo, almeno per me.
un primo cambiamento è arrivato quando, nel mio primo impiego come informatico (inizialmente un quasi sistemista), mi è stato chiesto di iniziare a sviluppare un prototipo di un sistema complesso (per me, per la mia esperienza, per la ridotta dimensione del gruppo di lavoro): una base di dati, un front-end web, un servizio di autenticazione, mettendo insieme software e hardware per un back-end di telefonia, agganciandosi infine ad un application server che fornisse un servizio di hosting. provando a documentarmi per capire come affrontare il progetto, in quel periodo è iniziato a nascere il mio amore per le architetture software. mi sono cimentato in letture come il classico "Desing-Patterns" della GoF (che nello stesso periodo stavo anche studiando in università), "Applying UML and Patterns" di Larman e "Patterns of Enterprise Application Architecture" di Fowler.
inevitabile, con l'entusiasmo arriva anche il fallimento: impossibile gestire la complessità senza avere feedback che quanto si sta disegnando funzioni realmente. ricordo benissimo lo sconforto di non riuscire a "far combaciare" tutti i pezzi, dopo averli pensati, nonostante la fatica e l'impegno messo per arrivare ad una soluzione soddisfacente. e ancora peggio, la difficoltà nel far adattare la struttura esistente ai continui cambi di requisiti. in fase di ricerca infatti, lavorando per un prototipo e non un prodotto, è lecito che il committente si svegli la mattina con una nuova geniale idea e ti chieda "e se facessimo così e così? e magari dopo potremmo anche attaccarci un servizio XYZ, che ne dici? proviamo?".
il secondo grande cambiamento per me poi è stato quando ho scoperto il testing automatico (anche questo visto per la prima volta in università). il vero traguardo però è stato imparare a sviluppare guidato dal testing; col tempo, facendo un sacco di errori, partendo dall'usare test di integrazione per grandi pezzi dell'applicazione ("ma come faccio a testare ancora più in dettaglio?") ho imparato a focalizzarmi su test unitari di singole piccole responsabilità. il Test-Driven Development mi ha insegnato che è possibile far evolvere il disegno partendo da una situazione più semplice e aggiungendo complessità di volta in volta: si chiama design evolutivo e incrementale. ci ho dedicato (a posteriori, direi con scarso successo) la mia tesi di laurea.
l'ultimo traguardo è sicuramente stato quando, infine, sono riuscito a fare mio il concetto che il codice sorgente di un'applicazione è il design del sistema. è stato grazie all'articolo di Jack Reeves "What is software design?", che affronta il tema in dettaglio e in modo davvero chiaro (è riportato anche in appendice nello splendido "Agile Principles, Patterns and Practices in C#" di Robert Martin). leggendo quell'articolo, ho finalmente avuto chiaro qualcosa a cui da sempre cercavo di dare forma, senza riuscirci: nel software, un'idea e valida se funziona, altrimenti rimane solo un'idea. e il nostro mestiere è davvero bello perchè ci permette di provare se le nostre idee sono valide: disegno e codifica non sono altro che due momenti diversi di uno stesso processo creativo. Kent Beck, nel suo "Smalltalk Best Practice Patterns" dice:
"To me, development consists of two process that feed each other. First you figure out what you want the computer to do. Then you instruct it to do it. Trying to write those instructions inevitably changes what you want the computer to do, and so it goes.
In this model, coding isn’t the poor handmaiden of design or analysis. Coding is where your fuzzy comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning."
come progetto il software? discuto, disegno qualcosa su carta, scrivo un test. come mi rendo conto se l'idea funziona? scrivo tutto e solo il codice che serve a far passare il test.
e poi semplifico, rifattorizzando.
è tutto, ciao
-papo-