Se, come il sottoscritto, vi occupate di consulenza vi sarà certamente capitato di provare enorme sconforto nell’imbattervi più volte in quella che ritengo essere la bestia nera del software nel nostro paese: l’assoluta carenza di architettura nei progetti.

UFO

Nel panorama italiano ancora dominato da webform, query SQL cablate a codice e spaghetti code, l’architettura è spesso fonte di perplessità per i team leader e considerato solo un costo dal management.

Nell’immaginario collettivo il nostro lavoro è semplice: basta comprare un libro e studiare un po’ per vivere nel proprio scantinato il sogno di Sean Parker o di Zuckerberg.

Basta che funzioni

Ci sono orde di giovani programmatori in giro per il mondo che scalano imponenti moli di documenti dei requisiti per far funzionare i loro sistemi a colpi di forza bruta.

Il codice che producono non sarà dei migliori ma funziona e lo fa perché far andare qualcosa, almeno una volta, è facile; Creare progetti chiari e manutenibili nel tempo è tutta un’altra storia.

Scrivere del buon software è complesso e richiede disciplina, capacità di analisi e una passione per il proprio lavoro che tanti programmatori non ritengono di dover avere, perché alla fine non c’è problema che non possa essere risolto con quattro forEach annidati, un paio di if e uno Switch case infinito.

Ma cosa si intende per architettura software e perché è tanto importante?

Ogni sistema software è costituito da due elementi ben distinti e di uguale importanza: il comportamento e la struttura.

Ogni sviluppatore dovrebbe garantire che la qualità
di entrambi gli elementi rimanga sempre alta.

Il comportamento definisce le funzionalità che ci aspettiamo dal nostro sistema, racchiuse e organizzate in documenti di analisi. (quando abbiamo la fortuna di averli!!!)

Compito del team è implementare e rilasciare tali funzionalità sulle macchine del cliente. In caso di anomalie il team corregge il problema e riesegue il deploy.

Missione compiuta?

La stragrande maggioranza dei programmatori ritiene che il nostro lavoro si fermi qui. Sbagliano di grosso e vediamo perché!

Durante la realizzazione di un sistema capita spesso che gli attori in gioco cambino idea su particolari funzionalità o decidano di aggiungere nuovi comportamenti al sistema.

Tale intervento dovrebbe essere semplice e agevole. Un’eventuale difficoltà dovrebbe al massimo essere proporzionale all’ampiezza e non riguardare la caratteristica della modifica.

Qui entra in gioco la struttura (o architettura). Essa definisce la forma che il nostro progetto deve avere, i componenti di cui è costituito e come questi interagiscono tra di loro.

La sua funzione è rendere il sistema scalabile e modificabile senza troppi sforzi.

La parola architettura non viene usata a caso: Il progetto di un palazzo ha in sé stanze e piloni costituiti da mattoni e travi d’acciaio. Se la qualità del mattone o delle fondamenta non è buona, l’intero palazzo risulterà scadente; se la disposizione delle stanze è lasciata al caso, la vivibilità della casa sarà compromessa.

L’obiettivo dell’ architettura del software, quindi, è quello di ridurre al minimo le risorse umane necessarie per realizzare e manutenere il sistema in questione.

Comportamento vs Architettura: cosa conta di più?

Quasi certamente la risposta da parte del management sarà: “è fondamentale che un programma funzioni e in tempi brevi”.

Gli sviluppatori spesso assecondano questo modello di business, rendendo interi sistemi trappole infernali impossibili da gestire.

Una breve analisi può essere utile per riflettere su quanto l’architettura sia importante:

• Un software perfettamente funzionante ma impossibile da modificare smette di funzionare alla prima modifica e, di fatto, diventa inutile.
• Un software semplice che non funziona può essere corretto facilmente e continua a funzionare a ogni nuova modifica.

Non trovate questa argomentazione convincente perché pensate che alla fine non esiste sistema impossibile da modificare?

Ebbene, la prossima volta che il vostro project manager darà in escandescenza perché il sistema che avete realizzato è così granitico da impedire una banale modifica, come un fantasma di forza mi abbatterò su di voi, sussurrando “Te l’avevo detto, Luke!”