Architettura Software: Introduzione, importanza e Compiti di un Sw Architect

A

introduzione

Ciao Coders,

oggi vi introdurrò’ il concetto di architettura software di un sistema, di quanto sia critica e importante la fase di progettazione e dei compiti della figura del software architect in un team.

architettura sw

Tra tutte le definizioni che si trovano in letteratura quella che mi aggrada di più e’ quella di Robert C. Martin in Clean Architecture:

L’architettura di un sistema software è la “forma” data a quel sistema da coloro che la costruiscono. Per  “forma” si intende la divisione di tale sistema in componenti, nella disposizione di essi e nei modi in cui tali componenti comunicano tra loro. Lo scopo è  quello di facilitare lo sviluppo, la distribuzione, il funzionamento e la manutenzione del sistema software in esso contenuto.

Direi una definizione chiara e concisa ma che allo stesso tempo contiene tutte le parole chiave di tale concetto. Alcuni di voi potrebbero rimanere sorpresi poiché’ spesso si  pensa che l obbiettivo principale di una Architettura sia quello di garantire il corretto funzionamento del sistema ma non e’ proprio cosi’.  Certamente vogliamo garantire che il sistema si comporti correttamente ma corretto funzionamento e buona architettura non sono strettamente concetti correlati: ho visto fin troppi sistemi funzionanti con dietro un architettura software da incubo. Lo scopo principale dell’architettura è invece supportare il ciclo di vita del sistema. Una buona architettura rende il sistema facile da capire, facile da sviluppare, facile da mantenere e facile da implementare. L’obiettivo finale è ridurre al minimo i costi della realizzazione del sistema e massimizzare la produttività del programmatore.

Cosa andiamo in contro quando un progetto ha una pessima architettura?

i problemi di una cattiva architettura sw

L’errore più’ comune che un developer alle prime armi commette e’ storicamente scrivere codice senza prima progettare l’architettura  software; in questi casi anche se l’obbiettivo viene raggiunto il software prodotto e’  di pessima qualità’:

  • scarsa manutenibilità’: una banale change arriva a impattare molti file e righe di codice; il tempo che hai risparmiato in fase di progettazione lo ritrovi speso con gli interessi nelle fasi successive, introducendo con grossa probabilità’ dei bug con la tua change.
  • difficile comprensione: con una architettura di bassa qualità’ la comprensione del software  ne risente notevolmente;  chi entra nel team  a progetto avviato o lo stesso sviluppatore a distanza di mesi fa un sacco di fatica a comprendere il codice. Verrete maledetti dai posteri che dovranno mettere mani allo schifo di software che avete scritto 🙂
  • scarsa riusabilità’: una pessima architettura implica grossi blocchi di codice e funzionalità’ duplicate nel tuo progetto. Se fai una fix su uno di questi blocchi duplicati ti devi ricordare di riportarla anche in altri N punti.
  • difficilmente testabile:  Ogni volta che uno sviluppatore cambia o apporta una modifica al codice, c’è sempre una piccola possibilità che anche un piccolo ritocco possa avere un impatto inaspettato sulle performance generali o le funzionalità del software su cui stai lavorando. Come intercettare bug o regressioni ? Sicuramente con una buona suite di test. Il presente articolo non tratta il testing, pertanto non mi dilungherò’ su questo importante argomento ma ci tengo comunque a  precisare che una cattiva progettazione del codice rende veramente difficile la fase di scrittura dei test automatici a causa di componenti troppo “grandi” e complessi con un alveare di dipendenze  che rendono difficile la realizzazione di unit test “puri” che garantiscono il principio di “isolation” del test del componente o il mocking delle dipendenze.

Possiamo quindi concludere che una pessima architettura condiziona gli attributi fondamentali che determinano la  Quality of Service 

 

Parliamo adesso della figura “misteriosa” del software architect.

software architect

La parola “architetto” e’molto figa 🙂 molti pensano che il software architect sia un manager, una figura di gestione del team che non si sporca le mani scrivendo codice. Ecco questo non e’ assolutamente vero! Prima di tutto un software architect e’ un developer, e continua ad essere un developer. Non cadete al luogo comune che  raffigura  gli architetti del software come figure che si ritirano dalla scrittura del codice per concentrarsi su problemi di livello superiore. Un buon software architect non lo fa! Un buon software architect e’ un ottimo programmatore, spesso uno dei più forti del team, il quale continua a prendere in carico task di sviluppo mentre guida il resto dei developer del team verso un design che massimizza la produttività’ e qualità’ del software. Il software architect magari non prende in carico lo stesso numero di task di un developer ma continua comunque ad impegnarsi nello sviluppo perché’ altrimenti non potrebbe fare bene il suo lavoro di architect se non fosse a conoscenza
della developer experience e dei problemi in fase di sviluppo che affliggono gli altri membri del team.

Analizziamo in dettaglio le fasi che cerca di ottimizzare un software architect in termini di costo azienda ed qualità’ del risultato.

1- sviluppo

Il principio KISS afferma che la maggior parte dei sistemi funziona meglio se vengono mantenuti semplici anziché complessi;
quindi la semplicità dovrebbe essere un obiettivo chiave nella progettazione e dovrebbe essere evitata la complessità non necessaria

_Principio KISS (Keep It Simple Stupid)_

Non dimentichiamo una cosa: i sistemi software devono essere gestiti da sviluppatori che sono umani e non macchine, quindi con capacità limitate!  Qualsiasi aumento della complessità di un sistema aumenta anche la difficoltà nel mantenerlo. Un sistema software difficile da sviluppare non avrà una vita lunga e sana! Un aspetto da tenere in conto in questa fase e’ la coordinazione del team di sviluppo: l’architettura e le scelte tecniche vanno concordate con tutto il team. Se un piccolo gruppo di tre o quattro sviluppatori può lavorare in modo abbastanza efficace per sviluppare un sistema monolitico senza componenti o interfacce ben definite, un azienda strutturata con più’ team che collaborano tra loro non può fare progressi a meno che il sistema non sia diviso in componenti ben definiti con interfacce note, documentate e stabili. Ti accorgi subito se stai lavorando in un progetto con un architettura SW ben progettata: se riuscite a parallelizzare il lavoro in più’ risorse senza pestarvi i “piedi” siete sulla strada giusta; se oltre le 3 o 4 risorse non riuscite a parallelizzare avete sicuramente qualche problema.

2- DEPLOY

Per essere efficace, un sistema software deve essere distribuibile. Maggiore è il costo di deployment, meno efficace è il sistema. Anche se non  e’ il ruolo chiave di un software architect, un buon software achitect deve comunque progettare un architettura software facilmente deployabile e su cui si possa applicare tecniche di Continuous Delivery e Deployment. Cruciale e’ la coordinazione tra il software architect e i Devops del team.

3- MANUTENZIONE

Di tutti gli aspetti di un sistema software, la manutenzione è la fase più costosa. La parata infinita di nuove funzionalità e l’inevitabile traccia di difetti e correzioni consumano enormi quantità di risorse umane.
Il costo principale della manutenzione è  dato dai seguenti punti:

  • il costo di analisi: Determinare il punto migliore e la migliore strategia per aggiungere una nuova change o per fixare un bug.
  • Il rischio e i side-effect di interventi: Quando si apporta modifiche ad un progetto la probabilità di creare bug è sempre presente. Questo problema si può’ attenuare facendo uso di test automatici nel progetto; gli sviluppatori possono eseguirli immediatamente prima di rilasciare i loro contributi verso l’ambiente condiviso, in modo da garantire che le modifiche non introducano errori nel software esistente. Tutto molto bello pero’ i test non nascono sugli alberi purtroppo! Vanno sviluppati e manutenuti; come tutte le cose tale attività’ va programmata e ha un costo. E’ necessario quindi trovare un buon compromesso tra i costi per automatizzare i test e i loro benefici.

Occorre tenere presente pero’ che una architettura attentamente studiata e progettata riduce notevolmente il costo di manutenzione:

  • Separando il sistema in componenti e isolando tali componenti attraverso interfacce stabili, è possibile identificare facilmente i punti in cui intervenire per le funzionalità future e ridurre notevolmente il rischio di introdurre un bug.
  • Una divisione in componenti e layer riduce drasticamente il costo di sviluppo dei test: e’ un fatto noto che componenti troppo “grandi” e complessi con un alveare di dipendenze  rendono difficile la realizzazione di unit test “puri” che garantiscono il principio di “isolation” del test del componente o il mocking delle dipendenze.

4- scalabilita

Oggi e’ un attimo passare da un regime di 100 utenti ad un bacino di  migliaia o milioni di utenti. Con una grossa mole di utenti e dati, le prestazioni di un sistema calano drasticamente. In questi casi entra in gioco la scalabilità’ del software progettato. E’ un argomento complesso, che tratteremo con uno o più articoli ma cercherò’ comunque di introdurvi tale concetto. La Scalabilità (scalability) e’ la capacità del sistema di gestire volumi di elaborazione crescenti nel futuro, se richiesto. Molti sistemi sono infatti soggetti a un qualche tipo di incremento nel carico di lavoro:

  •  un incremento di carico può riguardare, ad esempio, il
    numero delle richieste fatte dagli utenti al sistema oppure la
    mole di dati che il sistema dove gestire
  •  la scalabilità riguarda la capacità del sistema di accettare questi
    incrementi di carico, senza un impatto negativo nei confronti di
    altre qualità (in particolare, di prestazioni e disponibilità).

In The Art of Scalability [Abbott and Fisher] vengono presentati diversi principi
di progettazione di un architettura software che abbia capacita’ di scalare; i principali sono:

  • la scalabilità orizzontale va di solito preferita alla scalabilità
    verticale; Questo richiede di progettare per una distribuzione del carico
    su più nodi computazionali;
  •  inoltre, affinché il carico di lavoro possa essere distribuito su più
    nodi computazionali in modo efficace ai fini della scalabilità, il
    sistema deve essere preferibilmente basato su

    • interazioni asincrone
    • servizi stateless
    • e fare utilizzo di  caching

conclusioni

Con questo articolo abbiamo introdotto il concetto di Architettura SW, la sua importanza e quali sono i compiti di un software architect. Nel prossimo articolo proseguiremo ad approfondire tale tema: in particolare andremo a spiegare quali sono i principi noti in ingegneria del software che vengono utilizzati dai migliori software architect al mondo.

bibliografia e approfondimenti

  • Clean Architecture [Robert C.Martin]
  • The Art of Scalability [Abbott and Fisher]

 

A proposito di me

Dario Frongillo

Software architect con un forte background in Java, Architettura REST, framework Spring , Database Design,progettazione e sviluppo di SPA e RIA Web application con framework Javascript. Attualmente mi occupo di sviluppo soluzioni software in ambito Banking e Finance: in particolare progettazione e sviluppo di applicativi web based per la realizzazione di sistemi di trading, interfacce con i mercati finanziari e di servizi real time.

Gli articoli più letti

Articoli recenti

Commenti recenti