Architettura del Software: definizione e obiettivi
Tutti abbiamo almeno una idea vaga di cosa si intende per "Architettura del Software", ma penso che solo alcuni abbiano in mente concetti, pratiche e vantaggi precisi che ne derivano.
Architettura del Software: una definizione
Con Architettura del Software ci riferiamo alla struttura di un sistema software e alla progettazione delle interfacce dei suoi componenti; comprende le decisioni di progettazione che determinano quali parti compongono l'applicazione e come queste interagiscono e lavorano assieme per raggiungere gli obiettivi richiesti. Queste decisioni includono la struttura del file system (i file e le cartelle), la scelta dei framework da adottare, la definizione delle interfacce tra le diverse componenti che costituiscono l'applicazione, la gestione dei dati, la distribuzione delle responsabilità tra i moduli e altro ancora.
Un'architettura ben progettata facilita la manutenzione, l'aggiornamento e l'aggiunta di funzionalità del software nel tempo ponendo la giusta attenzione ad aspetti quali: la scalabilità, la sicurezza, la manutenibilità e la flessibilità per garantire che il software possa crescere e adattarsi alle esigenze in evoluzione.
Obiettivi ed effetti
Il fine ultimo di una buona Architettura del Software è quello di ridurre al minimo gli sforzi necessari alla realizzazione e manutenzione di un Sistema Software.
Gli effetti che una buona AdS ha sul progetto sono quelli di ridurre il numero di persone necessarie allo sviluppo, un numero inferiore di difetti ed una più semplice gestione degli stessi oltre che una maggiore flessibilità del codice prodotto. Un tale approccio allo sviluppo può avere effetti positivi sul Prodotto, sul Team e su tutta l'Organizzazione Aziendale.
La qualità di un AdS si misura, allora, in funzione dell'impegno necessario a far fronte alle richieste di modifica o evoluzione del software.
Gli effetti di una cattiva Architettura (sul Prodotto e sul Team)
La definizione e implementazione di una opportuna AdS sembra mal sposarsi con le esigenze di velocità e la mutevole natura dei requisiti cliente, in realtà...
La più grande bugia alla quale gli sviluppatori credono è che del codice mal realizzato li faccia andare più velocemente nel breve periodo e dia qualche lieve problema a lungo termine.
‐Robert C. Martin, Clean Engineering
Personalmente credo che tutti noi ci siamo trovati a pensare che "...Intanto lo scrivo così, in futuro lo sistemerò." Il futuro spesso dà un responso differente!
Una cattiva architettura del software può avere diversi effetti negativi nello sviluppo di un progetto web. Ecco alcuni dei principali.
- Difficoltà di manutenzione: un codice difficile da comprendere e modificare. Ciò comporta problemi durante la manutenzione, l'aggiornamento e l'implementazione di nuove funzionalità.
- Scalabilità limitata: un'architettura inadeguata potrebbe non essere in grado di gestire efficacemente un aumento del carico o delle richieste degli utenti.
- Rischi di sicurezza: una progettazione non sicura può esporre il sistema a vulnerabilità
- Difficoltà di testing: un'architettura disorganizzata può rendere difficile l'implementazione di test automatizzati efficaci.
- Costi elevati di sviluppo: la correzione di errori e l'aggiunta di nuove funzionalità su un'architettura mal progettata richiedono più tempo e risorse, aumentando i costi complessivi del progetto.
- Bassa riusabilità del codice: una cattiva architettura può portare a un codice poco modulare e scarsamente riutilizzabile.
- Difficoltà di collaborazione: l'assenza di una struttura chiara può portare a difficoltà nella collaborazione tra membri del team di sviluppo. Una buona architettura fornisce linee guida chiare su come il codice deve essere strutturato e interconnesso.
Per evitare questi problemi, è essenziale pianificare e progettare attentamente l'architettura del software fin dall'inizio del progetto, seguendo le migliori pratiche di Ingegneria del Software, adottando design pattern e principi di sviluppo SOLID.
Funzionalità o Architettura: cosa conta di più?
E' facile pensare che la funzionalità di un software sia la sua caratteristica principale: dopotutto è quello il motivo per cui lo stiamo sviluppando. L'Architettura che utilizziamo ha solamente lo scopo di servire tale funzionalità. Vi invito, però, ad una riflessione.
Proviamo a ragionare in termini di un programma che svolge perfettamente una funzione, ma non è modificabile in alcun modo (un esempio estremo, lo so...); ecco, quando cambiano i requisiti questo programma smetterà di erogare la funzionalità richiesta diventando di fatto un oggetto inutile. D'altro canto, un programma che non eroga la funzionalità richiesta, ma risulta facilmente modificabile, mi darà la possibilità di gestirlo e modificalo rendendolo utile ai miei fini.
Conclusione: la situazione da evitare
Le scelte architetturali devono essere effettuate nell'ottica di privilegiare la flessibilità del codice e a supporto del lavoro degli sviluppatori. Gli effetti positivi a medio e lungo periodo sono concreti e spaziano oltre i confini del Team di sviluppo.
La situazione, che un buon approccio architetturale, vuole evitare è quella di un progetto la cui manutenzione diviene col tempo e nelle successive release sempre più difficile ed onerosa per l'Azienda. Questa situazione può essere descritta nei due grafici qui sotto.
