Capire prima di imparare

Sottotitolo: riflessioni su pattern, framework, etc.

Ormai non ricordo nemmeno più da quanto tempo ho in mente di scrivere questo post ed alla fine, complice una giornata piovosa e poca voglia di scrivere codice, eccomi qui a buttare giù due righe sull’argometo.

Sia chiaro: nessuna “verità assoluta” anzi! Solo MIE personalissime riflessioni su argomenti in cui mi ci imbatto, vuoi o non vuoi, tutti i giorni.

Anche se apparentemente distanti, per me, il titolo (Capire prima di imparare) ed il sottotitolo (riflessioni su pattern, framework, etc.) sono fortemente legati tra loro. Ricordo ancora 2 professori di scuola superiore (i migliori che abbia mai avuto), uno di Fisica e l’altro di Elettronica, che ripetevano in continuazione:

“le cose le dovete capire, perchè solo capendole (bene) vi restano. Imparandole a memoria, le ricorderete per un po’, poi svaniranno”

Come dargli torto? Credo che questa sia una delle cose più importanti che ho imparato a scuola.

Capire prima di tutto, ed in tutte le cose, è il primo passo verso l’apprendimento. Diversamente, resteranno solo una serie (più o meno lunga), di buchi nella nostra memoria. Esempi di quanto ho appena detto ce ne sono a bizzeffe ed ogniuno di noi ne avrà sicuramente molti.

Quella frase, “capire prima di imparare“, ce l’ho ben stampata in mente e continua costantemente a risuonarmi, anche in questo momento. Non ho mai nascosto (in passato) ad esempio, la mia avversione verso i delegate (calma….ho detto “in passato!!!” tongue-out). Non che non fossi in grado di implementarli, per carità. Ma non li avevo capiti. E finchè non li ho capiti, ho avuto difficoltà ad impararli.

Se ci riflettete, sono sicuro che anche a voi verranno in mente tanti esempi come il mio.

E fin qui, è spiegato il titolo del post. Ma il sottotitolo? Che c’entra?

A mio modo di vedere, lo stesso ed identico discorso applicato ai miei delegate, si applica ai pattern, ai framework ed a tanti altri “amenicoli” che riguardano il nostro lavoro.

Prendiamo i pattern (tanto per iniziare). Fantastici, comodi, documentati. Basta aprire google, fare una ricerca ed abbiamo tutto sotto mano, compresi gli esempi di codice in quasi tutti i linguaggi, pronti per essere copiati ed incollati nelle nostre applicazioni. Perfetto! Fantastico!
Mi è capitato spesso di parlare con delle persone, di trovarmi in “chiacchierate da bar”, in cui i Singleton venivano serviti come noccioline, Domain Model come le olive in coppette di vetro, TableDataGateway e RowDataGateway li sul tavolo ad aspettare di essere presi da qualcuno. Ed il DataMapper? In abbondanza, senza parlare di Layer Supertype, che solo i più ferrati tiravano in ballo.

Scherzi a parte Smile, ad oggi sento tanta gente parlare di pattern come si parla della partita di calcio della domenica. Ma quanti ne hanno davvero capito l’essenza? Quanti ne hanno capito il senso? Personalmente ritengo che siano in pochi (occhio, non parlo assolutamente ne al livello mondiale, ne tiro in ballo gli Architetti – quelli veri, e non quelli che ce l’hanno scritto sul biglietto da visita). E sicuramente, io NON sono nel gruppo di quelli che li hanno capiti (non tutti almeno).

E’ facile, oggi, dare la definizione di Singleton (per prenderne uno facile) o di Domain Model (per andare su uno un pelino più complesso). E’ anche facile oggi dire: “qui serve il pattern A, che costruisce l’oggetto X attraverso il pattern B che…”. Quello che è più difficile, oggi, è capire il perchè serve il pattern A piuttosto che il pattern B.

E per capirlo, IMVHO, ci devi passare. E, sempre IMVHO, passarci vuol dire che devi buttare giù il codice, arrivare a capire che li, in quel punto, ti serve una sola istanza di quell’oggetto specifico, implementartela (magari sbagliando anche) e dopo, ma solo dopo, approdare al Singleton, che poi riuserai da qul momento in poi.

Si, magari messa così è troppo drastica. Probabilmente basta arrivare a quando dico “arrivare a capire che li, in quel punto, ti serve xxxxxx ” (sostituendo ad xxxxxx il nome del pattern che si è studiato sul GoF e/o sul PoEAA). Sarò io “di coccio” (probabilissimo), ma quando si parla di design pattern, una delle frasi più sensate che abbia mai sentito dire è (la quoto così risalta meglio nel template del blog Wink):

Il pattern deve emergere dal codice

Certo, avere persone che te li spiegano, che li hanno codificati in libri, che ne hanno scritto esempi anche in dialetto sardo, è comodo. Ma non basta.

Il mio personalissimo approccio ai pattern è:

  1. ho scritto (nel corso degli anni) molto codice
  2. ho individuato delle mie soluzioni comuni
  3. ho sentito parlare di pattern quali soluzioni a problemi che tutti i programmatori hanno (e mi son detto: “allora non sono solo io ad avere questa esigenza” tongue-out)
  4. mi sono documentato sui pattern, vedendo quali problemi risolvono e come lo fanno (senza scendere troppo nel dettaglio implementativo).
  5. progettavo il mio componente e lo implementavo.
  6. durante il ciclo di sviluppo, individuavo il problema comune e lo risolvevo a modo mio (sapendo che c’era già un patter adatto allo scopo – vedi punto 4).
  7. una volta capito il problema ed individuata la soluzione, mi andavo a vedere l’implementazione specifica del patter in oggetto.

Ovviamente, al punto 7 mi rendevo conto di aver sbagliato qualcosa, omesso qualcosa o, molto più spesso, di non aver tenuto in considerazione una serie di cose (e ci mancherebbe, diversamente il PoEAA lo avrei scritto io no? tongue-out). Ma ne ero felice, soprattutto perchè avevo la sensazione di aver imparato qualcosa di nuovo.

Perchè parlo al passato? Perchè oggi, ho attraversato i 7 punti già per diversi pattern e, per quelli già trattati e capiti, il flusso cambia. Oggi, già in fase di progettazione, individuo alcuni pattern (e molti me ne sfuggono ancora) quindi il discorso si semplifica notevolmente.

Mi si può obiettare che, facendo in questo modo, si perde tanto tempo. La mia
risposta, a chi mi solleva questa obiezione è: “tempo se ne va tanto, ma di sicuro non è perso“. A cui segue la “classica” domanda: “… e poi dipende da quello che vuoi fare da grande!“.

Lo stesso discorso si applica, IMHO, pari pari ai vari framework come Spring, NHibernate & CO.

Occhio! Non ne critico mica l’utilizzo, anzi! Quello che più mi lascia perplesso è il modo ed il motivo per cui vengono utilizzati, spesso con troppa superficialità.

Per come la vedo io, se prima non se ne capisce la vera essenza (e non la si capisce davvero se non si sono affrontate le problematiche in prima persona), si rischia di infilare pattern e framework ovunque, con il rischio di scrivere una applicazione la cui complessità è decisamente superiore a quella richiesta. Quanti utilizzano NHibernate passando prima dal Domain Driven Design di Evans?

Oggi, purtroppo, si cerca sempre la via più breve per raggiungere il proprio obiettivo. Questa cosa emerge dai vari forum, dai vari newsgroup e, molto spesso, dalle domande che vengono fatte durante gli eventi. E questo è un peccato perchè, per come la vedo io, si stà perdendo la vera essenza del nostro lavoro: quella di essere creativi, quella di sforzarsi di trovare una soluzione elegante e funzionale ad un problema.

Il mio timore è che, tra un po’, ci si trovi a costruire applicazioni intere trascinando, come in Workflow Foundation, i vari mattoncini che non saranno le classiche “activity”, ma pattern e framework vari.
Quale sarà il risultato?

Applicazioni belle da far vedere agli amici DEV, ma totalmente immanutenibili e di cui noi stessi non avremmo capito molto.

Concludo con un piccolo consiglio: sperimentate quanto più potete. E sperimentare NON vuol dire scaricare NHibernate ed infilarlo in una applicazione, ma scriverne una piccola, disegnare il Domain Model, mapparlo a mano, risolvere pian piano tutte le problematiche e, pian piano, arrivare ad NHibernate.

Fare il ragionamento contrario (devo implementare il pattern A, B e C; come faccio a metterli insieme) è, IMHO, sbagliatissimo.

Tags: