Ultimamente, per una serie di motivi, sto rileggendo alcune parti di “Domain Driven Design” di Eric Evans: ogni volta (e sarà almeno la quarta rilettura), emergono nuovi dettagli e “sento” di migliorare in maniera netta e profonda la mia capacità di design. Escludendo Goethe e “The catcher in the Rye” (che appartengono a Bounded Context differenti <g>), non ho difficoltà ad affermare che DDD sia, insieme a Refactoring, il libro che consiglierei a *tutti* coloro che abbiano un ruolo all’interno di un progetto IT; e quando dico “tutti”, intendo proprio “tutti”: ogni ruolo (analista, dev, architetto, project manager, …) ha “qualcosa” di importante da imparare da questi due testi. E, rileggendolo a qualche mese/anno di distanza, imparerà ancora. Ed ancora. Ed ancora. Ed ancora. E qui piazziamoci una bella ricorsione ad libitum :-)
E ciò fa a pugni con una parte di realtà professionale con la quale mi confronto quotidianamente: in Managed Designs riceviamo un significativo di richieste di corsi e, fatta la regola dell’80/20, l’80% delle richieste sono relative alla pura tecnologia. Ci viene richiesto un corso di NHibernate od Entity Framework, e non un corso su cosa un O/RM sia, come vada usato e su quale impatto abbia al livello architetturale. Ci viene chiesto: “fammi vedere come carico gli Ordini di un cliente con Entity Framework”, e non di capire cosa sia un fetch plan. Ci viene chiesto un corso di Silverlight & RIA Services e se si riesce a mettere in agenda “qualcosa” di MVVM c’è da leccarsi le dita, figurati se puoi provare a spiegare innanzitutto cosa sia Presentation Model (che esiste da una vita) e usare MVVM come una sua implementazione idiomatica.
Attenzione: non sto dicendo che i corsi tennologgici non abbiano importanza, sto dicendo che IMVHO sarebbe più importante chiedere dei corsi nei quali sia spiegato “come e perché” si appronti una soluzione e nei quali la tecnologia venga utilizzata per effettuare degli esempi, e non dei corsi nei quali l’unico “drive” sia la tecnologia stessa. Perché la tecnologia cambia, e se ciò che hai studiato è “solo” “quale metodo chiamo per fare X ma, ovviamente, prima ho dovuto impostare la proprietà Y al valore Z” beh… Ti ritroverai ad essere diventato un “guro” di Windows Forms che quando arrivano WPF e SL deve “rincorrere”, mentre se già in Windows Forms ti fossi “smazzato” Model View Presenter, trasferire skill (e magari anche recuperare codice) a Presentation Model MVVM sarebbe stato meno traumatico. Lo stesso dicasi per Web Forms vs. “MVC”, visto che Model 2 esiste da metà anni ‘90 (Struts anyone?). E il discorso potrebbe continuare citando: test, DIP/IoC, … e chi più ne ha più ne metta.
Certo, in un mondo nel quale nemmeno si sa che “quel pattern” in realtà si chiama Model 2 e *non* è MVC c’è poco da stupirsi. E non c’è nemmeno da stupirsi che “architetto” sia una buzzword che “fa figo” scrivere sul biglietto da visita, e non un ruolo che IEEE prima e ISO (mediante fast track) poi hanno definito in maniera standard sin dall’anno 2000 (10 anni, mica bruscolini). Che poi non è che lo standard sia perfetto, ma per criticarlo o negarne il valore bisognerebbe almeno conoscerlo, altrimenti sono solo chiacchiere. E se ha dei difetti, li si può correggere: l’iscrizione ad ISO ed ai suoi comitati è aperta a tutti. Tutti.
Altro che Software Factories: siamo un settore artigianale, e forse vogliamo rimanere tale. E magari non è nemmeno un male, se alla fin fine ciò che cerchiamo è la soddisfazione del nostro ego tecnico…
P.S.: ho chiuso i commenti perché, nel fortunato caso si sviluppasse una discussione sul tema, sarebbe bello mantenerla accessibile “nel tempo”, quindi ho creato un thread sul forum GUISA. Non sparate sul pianista: vorrebbe davvero essere lo spunto per una riflessione collettiva, perché io per primo sono interessato a capire meglio lo scenario…
posted @ giovedì 8 luglio 2010 15:22