Ho pensato un po' a questo post e lo vedo come un punto di passaggio in un percorso di crescita personale.

Negli ultimi anni mi sono interessato sempre maggiormente di architettura, in particolare l'architettura e l'approccio cosiddetto enterprise (industriale) hanno fortemente influenzato alcune mie scelte progettuali. Rivestendo il ruolo duale di specialista tecnico e di project leader mi sono trovato a prendere delle scelte a questo riguardo, scelte che ho preso dettate anche dall'esperienza, dall'intuito e dalla passione.

Sono convinto che l'architettura sia un elemento determinante della maturazione del processo di sviluppo informatico, uno strumento che serve per gestire ed organizzare la complessità del software, complessità sempre crescente. Utilizzando l'attributo complessità nella sua forma più generica additando sia ricchezza di requisiti, dimensione del sistema e complessità specifica di determinati processi.

La mia esperienza, anche negativa, mi ha portato a formulare alcuni idee che ho voluto rappresentare sotto il tema di ergonomia dell'architettura. L'obiettivo di questo post non è quello di insegnare o spiegare qualcosa ma semplicemente introdurre un concetto mettendo parzialmente in discussione l'approccio architetturale puro alla progettazione di un sistema informatico. In effetti penso che questa sia una visione agile dell'approccio architetturale alla progettazione del software.

L'approccio enterprise ad esempio prevede che si adottino determinati pattern per la progettazione, la realizzazione e l'esecuzione del software. I pattern di solito sono metodi e/o strutture ripetibili per l'implementazione di un aspetto di una soluzione. Volendo essere più precisi ci sono più aspetti di approccio enterprise oltre ai pattern ci sono, modelli di design, metodologie, eccettera.

Veniamo al dunque.

Tutte le scelte che producono metodologie o modelli di fatto producono "interfacce". Cioè strumenti con cui lo sviluppatore a diversi livelli interagisce per la costruzione del software. Il successo di vari strumenti è dovuto a vari fattori, cioè efficacia, affidabilità, specificità ma non solo, anche ergonomia. Cioè quelle caratteristiche che rendono uno strumento facilmente interfacciabile con l'uomo. (Basti pensare ad esempi reali di strumenti che hanno avuto particolarmente successo)

Se pensiamo ai linguaggi, alle librerie, ai framework, come strumenti, allora chi è l'utente che si deve interfacciare? Non è forse il programmatore.

Con l'accrescere della quantità e complessità dei requisiti, il programmatore deve raggiungere obiettivi di produttività e ricchezza funzionale sempre più elevati. Ecco perchè secondo me è appropriato introdurre l'argomento dell'ergonomia dell'architettura con l'obiettivo di definire architetture e realizzare strumenti più ergonomici per lo sviluppatore.

Faccio un esempio

Immaginiamo di dover utilizzare un servizio per effettuare un calcolo su un entità, non ci interessa definire il calcolo o l'entità ma il problema generico. Pensiamo al codice più semplice in un linguaggio ad oggetti come C#. E poi pensiamo all'utilizzo di una Object Factory per la creazione di oggetti (quest'ultima può essere uno strumento utile soprattuto in abbinamento a modelli di design o pattern quali Inversion of Control o Dependency Injection rendendo maggiormente scalabili i componenti in termini di configurabilità e composizione), la Factory richiede di essere configurata e crea un livello di isolamento rispetto alla costruzione degli oggetti.  In questo secondo caso diciamo che il servizio è definito da un contratto specificato con  un interfaccia denominata ICalcolatore che è implementata dalla classe Calcolatore.

Esempio A costruzione diretta dell'oggetto

Esempio B utilizzo di una Object Factory

Provo a definire una misura dell'ergonomia dei due differenti approcci utilizzati. Come primo elemento parliamo di leggibilità cioè cosa ci dice il codice, allora A mi dice che costruisco un oggetto di tipo Calcolatore, B mi dice che chiedo ad una classe Factory di restituirmi un oggetto di nome "Calcolatore" il quale implementa un interfaccia ICalcolatore. Come secondo elemento parliamo di conoscenza, cioè numeriamo gli elementi che si devono conosciere per utilizzando i due approcci, per A devo conoscere che esiste una classe che si chiama Calcolatore, per B devo conoscere che esiste una classe di nome Calcolatore, ed inoltre devo conoscere che esiste una configurazione che associa al nome logico "Calcolatore" un oggetto di classe namespace.Calcolatore, inoltre che Calcolatore implementa un interfaccia ICalcolatore, devo anche sapere che il servizio di fabbricazione degli oggetti è esposto attraverso metodi statici di una classe Factory in particolare che è definito un metodo GetObject che richiede di passare il nome logico dell'oggetto e ritorna un tipo object generico.

Se dovessi dare un giudizio generale di ergonomia mi verrebbe di dire che l'architettura di A è più ergonomica di B. (NOTA IMPORTANTE: Questo non significa che A è migliore di B o più scalabile o più elegante o più adatto o più efficiente ecc...)

Per chi si sta chiedendo perché di questa divagazione, in realtà ho visto e vissuto la frustrazione del programmatore che ricevute specifiche funzionali, scopre che per riuscire ad implementare qualcosa, deve acquisire una conoscenza molto estesa, articolata e a volte un po' frammentaria dell'architettura, dei servizi, della configurazione magari per implementare qualcosa che dal punto di vista funzionale è relativamente banale. Questo può succedere se si pensa solo in termini di scalabilità e architettura senza ragionare sull'agilità dell'architettura una volta applicata su un progetto di medie/grandi dimensioni.

Il messaggio è, per chi si occupa di architettura o di scelte specialistiche all'interno di un progetto mediamente strutturato: prestare attenzione all'impatto degli strumenti sui programmatori, cioè ai misuratori di quella che in questo contesto ho chiamato ergonomia dell'architettura, perché l'architettura e gli strumenti che si scelgono potranno avere effetto diretto sulla frustrazione degli sviluppatori, ma peggio ancora potranno inficiare la produttività e la qualità, soprattutto se si pensa in termini di crescita, rinnovamento o cambiamenti del software e del gruppo di lavoro.

L'obiettivo è di catalizzare uno spunto di riflessione, e stimolare a pensare alle architetture anche da un altro punto di vista, l'ergonomia, cioè il modo e la misura di quanto questi strumenti siano facili da imparare, manipolare, integrare e controllare per l'utente, cioè, lo sviluppatore.