La Clean Architecture si capisce in cinquant’anni

Questa intervista ruota intorno a Clean Architecture, il prodotto accelerato nel futuro dei concetti espressi in Clean Code e, come esso, lettura imprescindibile per architetti, analisti, progettisti e software manager.

Apogeonline: Clean Architecture succede a Clean Code? Oppure ne è un complemento? Piuttosto un fratello? Che relazione esiste tra i due libri, se esiste?

Robert Uncle Bob Martin: Si tratta di un nipote. Ha saltato una generazione. Se dovessi ordinare in modo appropriato i miei libri, la sequenza sarebbe questa:

1. Clean Code.
2. The Clean Coder.
3. Agile Software Development: Principles, Patterns, and Practices.
4. Clean Architecture.

Ti senti più felice quando progetti architetture oppure quando sviluppi buon codice?

Un codice pulito mi dà quel piacere semplice che soddisfa di una piccola cosa fatta come si deve. Una architettura pulita mi trasmette l’orgoglio sostanziale di un grande lavoro ben fatto.

Qual è la parte migliore di Clean Architecture?

L’inversione della dipendenza [se ne parla in più capitoli, in particolar modo nel Capitolo 5.]

Negli ultimi anni il lavoro dell’architetto software è cambiato? Se sì, come?

Sì e continua a cambiare anche oggi, perché ognuno usa una definizione differente della parola architetto. Per qualcuno sono come politici. Per altri, venditori. Oppure guide tecniche. Sono ruoli sempre fluttuanti, oggi e in passato, da un’azienda a un’altra.

Quali sono gli strumenti migliori per mettersi a progettare buone architetture software?

Carta quadrettata e una matita meccanica con punta da 0,5 millimetri.

Qual è l’errore più comune compiuto dai principianti che si accostano alle architetture software?

Pensare di comprenderle. Ottenere una buona visuale di come dovrebbe essere strutturato un sistema software richiede un certo numero di anni e lo studio (o l’esperienza) di un grande numero di fallimenti.

Tutti questi anni di lavoro… c’è un qualunque aspetto dell’architettura del software che agli inizi hai malcompreso, prima di arrivare alla soluzione più avanti?

Accidenti, sì. I principî autentici della buona architettura del software mi sono stati oscuri per i primi venticinque anni della mia carriera di sviluppatore. I temi su cui ho sbagliato più a lungo sono stati i ruoli architetturali della programmazione strutturata e della programmazione a oggetti. È solo da una decina di anni che ho iniziato ad afferrare il ruolo svolto nelle buone architetture dalla programmazione funzionale.

Che cosa scriveresti sopra l’ingresso di una ipotetica Università dell’Architettura Pulita?

Detach. Decouple. Distrust.

Cinquant’anni di esperienza per arrivare all’essenziale.