Il problema vero del lavoro in parallelo
Quando più persone, o più agenti, scrivono contemporaneamente su parti diverse dello stesso progetto, la cosa che si degrada per prima non è la qualità del singolo file. È la forma dell'insieme.
Ognuno risolve bene il proprio pezzo. Ma uno importa una funzione da un comparto che non dovrebbe conoscere, un altro duplica un concetto perché non sapeva che esistesse già, un terzo crea una dipendenza circolare fra due moduli che presi singolarmente sono impeccabili. Nessuna di queste cose fa fallire un test. Tutte insieme, dopo qualche mese, trasformano un progetto ordinato in un progetto che nessuno osa toccare.
Il vincolo che ci eravamo dati è quello dei comparti stagni: struttura per dominio, confini netti, nessun import trasversale. Se serve un dato di un altro comparto si passa da una porta dichiarata. È una regola facile da scrivere e impossibile da verificare a memoria su un progetto di qualche centinaio di file.
Cosa misura il grafo
Lo strumento legge il codice e ne ricava nodi, funzioni, componenti, moduli, voci di configurazione, e archi, cioè le relazioni fra loro: chi chiama chi, chi importa cosa. Poi raggruppa i nodi in comunità per densità di collegamento e calcola qualche indicatore strutturale.
Alla data dell'ultimo aggiornamento, questo sito è 1400 nodi e 2595 archi su 279 file, organizzati in 115 comunità. Nella fotografia precedente, dieci giorni prima e prima dei due giri di lavoro in parallelo, era 1056 nodi e 1887 archi su 210 file in 98 comunità.
Il numero che guardiamo per primo, però, è un altro: cicli di import rilevati, nessuno. Significa che nessuna coppia di moduli si importa a vicenda, direttamente o attraverso una catena. È la verifica automatica di una regola che avevamo scritto solo in prosa. Il vincolo dei comparti stagni ha retto anche dopo il lavoro in parallelo, e non lo sappiamo perché ci fidiamo: lo sappiamo perché è stato calcolato.
I nodi più connessi raccontano cosa conta davvero
La parte più interessante non sono i totali, sono le classifiche. Lo strumento elenca i nodi con più collegamenti, quelli che di fatto sono le astrazioni portanti del progetto, che ci piaccia o no.
In cima ci sono le cose che ci aspettavamo: la funzione che dice se l'utente ha chiesto meno animazioni, con quarantaquattro collegamenti, perché ogni modulo di movimento la interroga prima di fare qualsiasi cosa. Poi i lettori dei contenuti, con trentasei e trentuno collegamenti: le impostazioni del sito e i presidi territoriali, che risalgono perché il territorio ora si legge da un vocabolario unico invece che da testi scritti a mano in cinque punti diversi.
Poi c'è la sorpresa. In sesta posizione, con diciotto collegamenti, c'è il componente che dichiara uno spazio per un'immagine che non abbiamo ancora prodotto. Non è un dettaglio grafico: è una struttura portante del sito. È la misura della nostra regola sui visual, quella per cui un buco si dichiara invece di riempirlo con una foto di repertorio. Se qualcuno domani decidesse di cancellare quel componente, scoprirebbe dal grafo che sta togliendo un pezzo di ossatura.
Questo è il tipo di cosa che una riunione non produce. Nessuno avrebbe messo quel componente in una lista dei cinque elementi centrali del progetto, e invece lo è.
Dove il grafo non aiuta
Onestà d'obbligo, perché sono limiti che abbiamo incontrato.
Il grafo dice come il codice è connesso, non se è buono. Un modulo pessimo con poche connessioni resta invisibile, un modulo ottimo e molto usato appare identico a uno mediocre e molto usato.
Il grafo invecchia. È costruito da un commit preciso e va rigenerato dopo le modifiche, altrimenti descrive un progetto che non esiste più. Nel nostro caso la rigenerazione non costa nulla in termini di modelli, perché la quasi totalità delle relazioni viene estratta leggendo il codice e non inferita, ma va comunque fatta, e va fatta automaticamente o non la fa nessuno.
Il grafo segnala anche i buchi, e i buchi sono tanti. Nel nostro ci sono cinquecentottantatré nodi quasi isolati, con una connessione o nessuna. Alcuni sono normali, sono tipi e costanti locali. Altri sono davvero pezzi che non si collegano a niente e che varrebbe la pena guardare. Sapere di averli è già un guadagno rispetto a non saperlo.
Perché lo chiamiamo memoria e non documentazione
Un documento di architettura racconta l'intenzione. Il grafo racconta il risultato. Quando i due divergono, e divergono sempre, il documento va riscritto, non il grafo.
Per un progetto in cui parte del codice viene scritta da agenti che non hanno memoria fra una sessione e l'altra, questa distinzione diventa operativa. Un agente che riparte da zero non ricorda le decisioni prese tre settimane prima. Se le decisioni vivono solo nella testa di chi c'era, si perdono. Se vivono in un artefatto rigenerabile e verificabile, si possono rileggere.
La domanda che apriva questo articolo, come faccio a sapere che l'architettura regge, ha una risposta banale una volta trovata: la si misura. Il costo è qualche minuto per aggiornare un file. Il costo di non farlo è accorgersi fra sei mesi che i comparti stagni non erano più stagni da cinque.
