[Pubblichiamo la postfazione al libro Clean Architecture di Robert Uncle Bob Martin, sull'applicazione di regole alle architetture software per migliorare la produttività degli sviluppatori e il ciclo di vita delle applicazioni.]
La mia carriera professionale, come sviluppatore di software, è iniziata negli anni Novanta, un’epoca dominata dai dinosauri della Big Architecture. Per poter vivere, dovevi studiare gli oggetti e i componenti, i modelli di progettazione e il linguaggio UML (e i suoi precursori).
I progetti (e… ragazzi, dovremmo forse rimpiangere i tempi in cui abbiamo deciso di chiamarli così?) iniziavano con lunghe fasi di progettazione, dove i programmatori senior tracciavano i piani dei sistemi e i programmatori junior dovevano seguirli. Cosa che, ovviamente, essi non facevano. Mai.
Chi comanda
Fu così che, dopo essere diventato software architect e poi lead architect, chief architect, Lord Architect of the Privy Council (e tutti gli altri titoli altisonanti che ci attribuivamo al tempo) pensavo di essere condannato a trascorrere le mie giornate a tracciare frecce fra riquadri e a scrivere codice PowerPoint, senza aver mai quasi nessun impatto sul codice vero.
Mi colpì il fatto che questa era un’assurdità: ogni riga di codice contiene almeno una decisione di progettazione, e quindi chiunque scrivesse codice aveva un impatto sulla qualità del software molto più grande di un giocoliere di PowerPoint come me.
L’estinzione dei dinosauri
E poi, per fortuna, arrivò la rivoluzione dello sviluppo del software Agile, che ha salvato dalla miseria professionale gli architetti come me. Io sono un programmatore. Mi piace programmare. E il modo migliore che ho trovato per avere un impatto positivo sul codice è scriverlo.
I dinosauri della Big Architecture, che in genere pascolano nelle lande primordiali del Big Process, sono stati spazzati via dall’asteroide dell’Extreme Programming. E benedetto sia il suo arrivo…
Regole di programmazione che hanno dominato il mondo, ma si sono oramai estinte.
A questo punto i team di sviluppo erano liberi di concentrarsi su quello che contava e di concentrare i propri sforzi sulle cose di valore. Invece di aspettare settimane o mesi un documento di Big Architecture da ignorare ossequiosamente per scrivere il codice che avrebbero comunque scritto, i team potevano semplicemente accordarsi su un test con i loro clienti, indire una sessione di progettazione rapida per orientarsi e poi scrivere il codice che avrebbero comunque scritto.
I dinosauri della Big Architecture si erano estinti; ci sostituirono i piccoli e agili mammiferi della Minima-Progettazione-Iniziale-e-Ampio-Refactoring. L’architettura del software divenne reattiva.
Be’, questo in teoria…
Palle da biliardo
Il problema di lasciare l’architettura ai programmatori è che a quel punto i programmatori devono essere in grado di pensare come architetti. Ovviamente non tutto quello che avevamo appreso durante l’era della Big Architecture era insensato. Il modo in cui viene strutturato il software può avere un profondo impatto sulla nostra capacità di adattarci e di evolvere, anche a breve termine.
Ogni decisione progettuale deve lasciare la porta aperta ai cambiamenti futuri. Come nel gioco del biliardo, ogni colpo non serve solo a mandare la palla in buca; si tratta anche di preparare il colpo successivo. Scrivere del codice funzionante che non pregiudichi le future espansioni è un talento non banale. Ci vogliono anni per impadronirsene.
E così, l’era della Big Architecture cedette il posto alla nuova era della Fragile Architecture: progetti che crescevano rapidamente per iniziare a produrre il più in fretta possibile, ma che hanno finito per rendere insostenibile quel ritmo di innovazione.
È facile parlare di “abbracciare il cambiamento”, ma se cambiare una riga di codice costa 500 dollari, il cambiamento non si verifica.
Sono molte le attività dove è meglio agire e intanto preparare la prossima mossa.
Dalla teoria alla pratica
I testi di Bob Martin sui principi della progettazione OO hanno avuto un grande impatto su di me come giovane sviluppatore di software. Potevo guardare il mio codice da una nuova prospettiva e notare problemi che, fino ad allora, non mi sembravano tali.
Avete visto come sia possibile scrivere codice che offra valore oggi senza pregiudicare il suo valore futuro; ora avete l’onere di mettere in pratica quanto avete appreso, e di applicare questi principi al vostro codice.
È come andare in bicicletta: non si può imparare la progettazione di software solo leggendo testi che ne parlano. Per trarre il meglio da un libro come questo, occorre la pratica. Analizzate il vostro codice e cercate i tipi di problemi evidenziati da Bob, poi esercitatevi nel refactoring del codice, per risolvere tali problemi. Se non siete ancora esperti di refactoring, questa sarà un’esperienza doppiamente preziosa.
Imparate a incorporare i principi della buona progettazione e l’architettura clean nei processi di sviluppo, in modo che il vostro nuovo codice abbia più probabilità di successo. Per esempio, se state sviluppando in TDD, considerate la possibilità di eseguire una piccola revisione della struttura del software dopo aver superato i vari test e ripulite il codice mentre procedete (è molto più economico che correggere un cattivo progetto troppo tardi). Magari, prima di consegnare il codice, chiedete a un collega di rivederlo con voi. E osservate la possibilità di prevedere un “controllo di qualità” del codice per la vostra pipeline di build, come ultima linea di difesa contro un’architettura non pulita. E se non avete una pipeline di build, forse è il momento di crearne una…
Parliamo di qualità
Ma è importante parlare di un’architettura clean. Parlatene con il vostro team. Parlatene con l’intero gruppo di sviluppatori. La qualità è qualcosa che interessa tutti, ed è importante raggiungere il consenso sulla differenza tra architettura buona e cattiva.
Ricordate che la maggior parte degli sviluppatori non fa molto attenzione all’architettura, proprio come me 25 anni fa. Sono stati gli sviluppatori più esperti a indirizzarmi in tal senso. Una volta che vi sarete convinti a sviluppare adottando un’architettura clean, dedicate del tempo a convincere qualcun altro. Portatevi avanti.
Mentre il panorama tecnologico per gli sviluppatori evolve continuamente, i principi fondamentali come quelli descritti in queste pagine cambiano raramente. Ho pochi dubbi sul fatto che questo sia un libro che rimarrà sul vostro scaffale per molti anni dopo che la vostra copia di Lean JSON Cloud NoSQL for Dummies sarà finita sul banco dei titoli in svendita. Spero che questo libro rappresenti per voi quello che i primi testi di Bob hanno rappresentato per me.
Il vero viaggio inizia qui.
Le regole di pulizia e rigore che cambiano la programmazione.
