ARCHITETTURA E SVILUPPO AGILE
Definizioni di Architettura
Gli sviluppatori che adottano metodologie “Agili” hanno spesso opinioni contrastanti riguardo all’architettura di un software, a volte addirittura arrivando a dire che l’architettura non esiste.
Proviamo a ragionarci e cerchiamo prima di tutto di dare delle definizioni di architettura:
- Architettura: decisioni difficili da riconsiderare in quanto il rivederle avrebbe un costo eccessivo
- Architettura software: la “forma” e il “flusso” di un software indipendentemente dal dominio del problema ma dipendente dalla user-experience
Vediamo le definizioni singolarmente.
Architettura in termini generali
Molti dei “guru” in campo informatico hanno dato la loro definizione di architettura. Prendiamo ad esempio Simon Brown che nel suo doppio volume Software Architecture for Developers dice:
“Architetcture represents the significant decisions that shape a system, where significance is measured by cost of change”
ossia “L’archiettura è rappresentata dalle decisioni significative che danno forma al sistema, dove la “significatività” è misurata in termini di costi necessari per cambiarle” e prosegue con “The architectural decisions are those that you can’t reverse without some degree of effort” ossia “Le decisioni architetturali sono quelle che non si possono rivedere senza l’impiego di una certa dose di effort”.
LE NOSTRE COMPETENZE
Lavoriamo con le più recenti tecnologie
Possiamo creare qualsiasi progetto tecnologico, utilizzando e combinando numerosi framework e linguaggi di programmazione, per risultati che supereranno le tue aspettative.
Le tre macro-architetture software più largamente e comunemente utilizzate sono:
- Request/response. Viene fatta una richiesta al sistema e si attende la risposta
- Event driven. Gli Eventi di business avvengono e gli Attori del sistema devono reagire ad essi. Lo stato del sistema può essere interrogato
- Batch. Il Sistema processa i dati senza l’intervento dell’utente a intervalli più o meno stabiliti.
Macro-Architetture 1
Dettagli architettura request/response
È molto comune per le web-application avere una architettura request/response, per quanto diversi possano essere i domini applicativi quasi tutte ricadono nello stesso schema di domanda e risposta (request/response appunto).
Non solo! Se consideriamo gli applicativi a linea di comando si può vedere che anch’essi seguono una architettura di tipo request/response e se andiamo ad esaminare il loro codice si potrà verificare che sono strutturati in maniera simile alle web-application.
Indice quindi che, come detto, l’architettura software è indipendente dal dominio applicativo ma dipende dalla user-experience prevista.
Macro-Architetture 2
Dettagli architettura event-driven
Un videogame, invece, è il tipico esempio di una architettura di tipo event-driven in cui gli attori e gli eventi avvengono, anche, indipendentemente da quanto stia facendo l’utente.
Allo stesso modo molti sistemi distribuiti seguono una architettura di tipo event-driven in cui i vari nodi reagiscono e generano eventi che vanno a cambiare lo stato complessivo del sistema.
Un’altra volta vediamo come l’architettura non è definita dal dominio, e quindi dai requisiti funzionali, bensì dalla user-experience e dai requisiti non funzionali.
Macro-Architetture 3
Dettagli architettura batch
Un ragionamento analogo può essere fatto per i sistemi basati su architetture di tipo batch in cui il sistema processa i dati senza la necessità di intervento di un utente. Sono tutti strutturati in maniera simile indipendentemente dal dominio applicativo.
Risulta chiaro che il dover cambiare tipo di architettura (ad esempio da request/response a event-driven) è un’operazione molto onerosa e rischiosa.
Quando gli sviluppatori Agile determinano l’architettura?
Lo sbaglio che molti sviluppatori agili fanno è pensare che l’architettura di un sistema emerga spontaneamente semplicemente applicando le tecniche di TDD (Test Driven Development) e Refactoring, cosa che invece non succederà.
L’architettura è una decisione critica, di fatto non sarebbe nemmeno possibile iniziare a fare del TDD prima di aver definito l’architettura in quanto i test sono necessariamente vincolati a come il software sarà strutturato e a come il “flusso” sarà definito.
Questo implica che l’architettura deve essere definita prima di iniziare lo sviluppo.
Ma, allo stesso tempo, un bravo sviluppatore agile sa bene che non è possibile, e non ha nemmeno senso provarci, cercare di capire e carpire tutti i dettagli di un nuovo sistema preventivamente e tardare gli sviluppi fino a quel termine. Sa invece che prima riuscirà a dare al cliente un sistema funzionante prima riuscirà ad avere dei feedback e capire quali assunzioni fatte erano giuste e quali sono sbagliate andando di conseguenza ad aumentare la propria conoscenza sul dominio e su che tipo di user-experience il cliente si aspetta.
Questo implica che l’architettura verrà definita anche durante lo sviluppo del software.
Sebbene le due asserzioni siano contrastanti questa è la
realtà dei fatti che non può essere ignorata e significa che nuove user-stories
(requisiti funzionali) potranno indicare delle user-experience o dei vincoli
(requisiti non funzionali quali performance aspettate, high availability,
sicurezza) che non si sposeranno bene con l’architettura precedentemente
impostata.
Quello che un bravo sviluppatore agile dovrà fare non sarà tanto snaturare
quanto richiesto dal cliente per includerlo in un’architettura non adatta bensì
dovrà o rivedere l’architettura in toto o far accomodare nel proprio sistema
diverse architetture. Ovviamente la cosa non è semplice e richiederà abilità e
tempo, condizioni che dovranno essere illustrate, discusse e spiegate al
cliente.
Architettura e metodologia Agile
Conclusioni
Dato che l’architettura è la parte più costosa da rivedere in un sistema allora è bene porre particolare attenzione alla sua prima definizione.
Essendo l’architettura definita dalla user-experience aspettata (in primis se request/response o event-driven) e dai requisiti non funzionali, anche detti di qualità, come le performance, la SLA richiesta, il numero di utenze previste e il livello di sicurezza allora è necessario chiarire innanzitutto tali aspetti con il cliente, ancora prima di avere chiaro il dominio applicativo.
Come tutto durante lo sviluppo di un software anche tali aspetti possono cambiare e bisogna reagire di conseguenza o cambiando architettura o incorporando più architetture nel sistema. In tali casi va fatta capire al cliente la necessità e la complessità dell’operazione che risulta però necessaria per raggiungere gli obiettivi richiesti.
