Perchè applicare un "Design Pattern"
"Nell'ingegneria del software, un design pattern (schema di progettazione) può essere definito una soluzione progettuale generale a un problema ricorrente.". Questa è la prima frase che riporta Wikipedia quando si cerca la voce "Software Design Pattern".
I più arguti avranno già capito che questo post non è di natura empirica (quindi condito da tanto "succoso" codice); più che altro è l'ennesima "sbrodolata" concettuale-filosofica a tema informatico. Si, perchè essere appassionati di informatica è un po' essere filosofi e teorici della materia, capire i principi ispiratori, farli propri ed applicarli alla pratica quotidiana.
Ritengo che il nostro mestiere sia una di quelle professioni che più richiedono dedizione e passione. Si studia per anni ciò che hanno fatto quelli che sono venuti prima di noi; si fa esperienza sul campo, versando sangue e lacrime ogni giorno. Alla fine ci si sveglia una mattina convinti di sapere (più o meno) tutto quello che serve per andare avanti per i prossimi cinque o sei anni, per poi scoprire che è uscita la nuova meraviglia ("The next big thing", per dirla all'americana) che spazza via tutte le nostre certezze, e ci costringe a studiare ancora per non cadere nell'oblio dell'obsolescenza.
E' quindi cosa buona e giusta aggiornarsi quotidianamente su quello che propone in mercato. Ma è altrettanto giusto applicare quelle conoscenze in funzione di pratiche di programmazione (o "ingegnerizzazione del software") che ci permettano di realizzare un sistema informativo solido, ben organizzato, ma sopratutto in grado di resistere alle insidie del tempo.
Un sistema può essere "cool" quanto si vuole e fare uso dell'ultimissima tecnologia, ma se è studiato e realizzato architetturalmente male, è equiparabile al classico castello di carte. E più diventa ampia la costruzione, più la sua fragilità e l'instabilità sono il motivo di un probabile fallimento del progetto.
Durante la mia breve carriera, ho visto (e vedo ancora) tantissimi colleghi che, analisi funzionale alla mano, aprono l'ambiente di sviluppo e iniziano a scrivere codice a testa bassa. Essere "aggressivi sulla tastiera" per produrre quante più classi e metodi possibile. Per poi arrivare a cosa? Ad un punto di non ritorno, dove una piccolissimo ostacolo, apparentemente insignificante, diventa una montagna insormontabile, che costringe il più delle volte a degli "accrocchi" senza senso per andare oltre.
Non è il numero di righe di codice scritte la misura con cui si determina la produttività di uno sviluppatore; ma è piuttosto la capacità di arrivare alla stessa soluzione (o una migliore) prediligendo la qualità alla quantità, usando maggiormente la materia cerebrale e meno le falangi.
I patterns, sopratutto quelli architetturali, essendo sintesi dell'esperienza degli sviluppatori che ci hanno preceduto, rappresentano il "succo della saggezza". Ci aiutano a creare uno scheletro solito per la nostra applicazione; una base su cui poggiare il nostro lavoro e la nostra fatica, con ragionevole certezza di avere sempre una soluzione anche per il problema più remoto che può accadere (nel limite dell'umana comprensione, certo).
E' fondamentale capire il motivo recondito per cui quel modo di procedere è stato formalizzato; il significato che si nasconde dietro a delle scelte, a volte apparentemente "assurde" e "cervellotiche". Capire se quello è "il pattern" che fa al caso nostro per quella specifica situazione.
E come ha detto una volta il buon Mauro Servienti, applicare un design pattern in maniera "talebana" quando lo si conosce poco o nulla, paga parecchio. L'applicazione "rigida" ci mette al sicuro da problematiche in cui possiamo incorrere, e che il "formalizzatore" (l'autore) ha già affrontato e risolto, guidandoci quindi nella realizzazione di un software più coerente e scalabile.
Quando poi arriviamo al punto di dominare la tecnica in questione, ci si può anche prendere la "licenza" di andare fuori dal seminato, tentare una nuova strada, e magari migliorare la sua stessa applicazione con una "revisione" che farà del bene alla nostra autostima e aiuterà tanti colleghi impantanati in una situazione già vissuta...
"Usa la testa, Luke..."
I più arguti avranno già capito che questo post non è di natura empirica (quindi condito da tanto "succoso" codice); più che altro è l'ennesima "sbrodolata" concettuale-filosofica a tema informatico. Si, perchè essere appassionati di informatica è un po' essere filosofi e teorici della materia, capire i principi ispiratori, farli propri ed applicarli alla pratica quotidiana.
Ritengo che il nostro mestiere sia una di quelle professioni che più richiedono dedizione e passione. Si studia per anni ciò che hanno fatto quelli che sono venuti prima di noi; si fa esperienza sul campo, versando sangue e lacrime ogni giorno. Alla fine ci si sveglia una mattina convinti di sapere (più o meno) tutto quello che serve per andare avanti per i prossimi cinque o sei anni, per poi scoprire che è uscita la nuova meraviglia ("The next big thing", per dirla all'americana) che spazza via tutte le nostre certezze, e ci costringe a studiare ancora per non cadere nell'oblio dell'obsolescenza.
E' quindi cosa buona e giusta aggiornarsi quotidianamente su quello che propone in mercato. Ma è altrettanto giusto applicare quelle conoscenze in funzione di pratiche di programmazione (o "ingegnerizzazione del software") che ci permettano di realizzare un sistema informativo solido, ben organizzato, ma sopratutto in grado di resistere alle insidie del tempo.
Un sistema può essere "cool" quanto si vuole e fare uso dell'ultimissima tecnologia, ma se è studiato e realizzato architetturalmente male, è equiparabile al classico castello di carte. E più diventa ampia la costruzione, più la sua fragilità e l'instabilità sono il motivo di un probabile fallimento del progetto.
Durante la mia breve carriera, ho visto (e vedo ancora) tantissimi colleghi che, analisi funzionale alla mano, aprono l'ambiente di sviluppo e iniziano a scrivere codice a testa bassa. Essere "aggressivi sulla tastiera" per produrre quante più classi e metodi possibile. Per poi arrivare a cosa? Ad un punto di non ritorno, dove una piccolissimo ostacolo, apparentemente insignificante, diventa una montagna insormontabile, che costringe il più delle volte a degli "accrocchi" senza senso per andare oltre.
Non è il numero di righe di codice scritte la misura con cui si determina la produttività di uno sviluppatore; ma è piuttosto la capacità di arrivare alla stessa soluzione (o una migliore) prediligendo la qualità alla quantità, usando maggiormente la materia cerebrale e meno le falangi.
I patterns, sopratutto quelli architetturali, essendo sintesi dell'esperienza degli sviluppatori che ci hanno preceduto, rappresentano il "succo della saggezza". Ci aiutano a creare uno scheletro solito per la nostra applicazione; una base su cui poggiare il nostro lavoro e la nostra fatica, con ragionevole certezza di avere sempre una soluzione anche per il problema più remoto che può accadere (nel limite dell'umana comprensione, certo).
E' fondamentale capire il motivo recondito per cui quel modo di procedere è stato formalizzato; il significato che si nasconde dietro a delle scelte, a volte apparentemente "assurde" e "cervellotiche". Capire se quello è "il pattern" che fa al caso nostro per quella specifica situazione.
E come ha detto una volta il buon Mauro Servienti, applicare un design pattern in maniera "talebana" quando lo si conosce poco o nulla, paga parecchio. L'applicazione "rigida" ci mette al sicuro da problematiche in cui possiamo incorrere, e che il "formalizzatore" (l'autore) ha già affrontato e risolto, guidandoci quindi nella realizzazione di un software più coerente e scalabile.
Quando poi arriviamo al punto di dominare la tecnica in questione, ci si può anche prendere la "licenza" di andare fuori dal seminato, tentare una nuova strada, e magari migliorare la sua stessa applicazione con una "revisione" che farà del bene alla nostra autostima e aiuterà tanti colleghi impantanati in una situazione già vissuta...
"Usa la testa, Luke..."
Commenti
Posta un commento