L'arco di dipendenza che ti mente

Chiedi a un team di piattaforma il suo diagramma di architettura e riceverai una di due cose: una pagina Confluence con il timbro "ultima modifica 14 mesi fa", oppure un'alzata di spalle e un thread su Slack in cui tre persone discutono se il servizio dei pagamenti chiami ancora inventory direttamente o sia passato attraverso l'event bus nella migrazione del Q3 che nessuno ha finito di documentare. Entrambe le risposte sono corrette, nel senso che entrambe descrivono quello che succede davvero nella maggior parte dei team oltre una certa dimensione.

Il diagramma non è sbagliato perché qualcuno è stato pigro. È sbagliato perché un diagramma è un'affermazione sul sistema congelata nel momento in cui qualcuno lo ha disegnato, e il sistema ha continuato a evolversi. Ogni dipendenza che non hai rimosso, ogni nuova chiamata che qualcuno ha aggiunto sotto pressione di scadenza con l'intenzione di ripulirla poi, ogni percorso di fallback che scatta solo in produzione — niente di tutto questo compare in un diagramma di scatole e frecce a meno che qualcuno non torni indietro e lo ridisegni. Nessuno lo ridisegna. Quel divario tra il sistema come documentato e il sistema come funziona realmente è ciò che intendiamo con architectural drift, e non è un'ipotesi: è lo stato predefinito di qualsiasi sistema abbastanza vecchio da essere stato toccato da più di un ingegnere.

Due fonti di verità, e nessuna delle due basta da sola

L'analisi statica legge quello che hai scritto: parsifica il codice sorgente, risolve gli import, segue i client HTTP e i listener Kafka, e ottieni un grafo di ciò che il codice dice dovrebbe chiamare cosa. È precisa ed economica da calcolare, ma conosce solo i percorsi che esistono nel sorgente — un feature flag che è al 100% da otto mesi e non ha mai avuto il ramo vecchio eliminato appare comunque "usato" a una lettura puramente statica, e una chiamata che avviene solo tramite reflection o un URL costruito dinamicamente potrebbe non comparire affatto.

L'osservazione a runtime è lo specchio opposto. Guarda il traffico reale — quale porta ha parlato con quale container, con che frequenza, quanto velocemente — e ottieni esattamente ciò che sta succedendo adesso, senza bisogno di interpretazione. Ma i dati di runtime non hanno memoria dell'intento. Non possono dirti se una chiamata è stata progettata di proposito o è un residuo che nessuno si prende la briga di rimuovere, e se il campione di traffico non cattura un batch job notturno che gira una volta al giorno, quella dipendenza gli resta invisibile.

Nessuna delle due mente, esattamente. Entrambe dicono la verità su una domanda diversa.

Cosa ti compra davvero taggare ogni arco

La mossa utile non è scegliere una fonte rispetto all'altra — è tenerle entrambe e rifiutarsi di fonderle in un unico fatto senza etichetta. Ogni arco di dipendenza nel grafo di Archynt porta con sé la sua origine: static (trovato nel sorgente, mai osservato live), runtime (osservato nel traffico, non scritto da nessuna parte), o both. Quel terzo stato, confirmed_by: both, è l'unico su cui puoi agire con fiducia reale — significa che il codice e il cavo sono d'accordo.

Gli altri due sono dove vivono le scoperte interessanti. Un arco solo static senza traffico runtime da settimane è un candidato a codice morto — una dipendenza che probabilmente puoi eliminare, e ora hai una prova invece di un'ipotesi. Un arco solo runtime è l'opposto e, nella nostra esperienza, il più urgente: una dipendenza viva che nessuno ha annotato, il che significa che nessuno la possiede, nessuno ha allarmi su di essa, e la prossima persona che tocca il servizio chiamante non ha idea che sia critica finché non la rompe.

Perché questa è una conversazione sul rischio, non sulla documentazione

È tentante archiviare il drift sotto "tenere la documentazione aggiornata", ed è esattamente per questo che la maggior parte dei team non lo risolve mai — il debito di documentazione perde ogni riunione di prioritizzazione contro qualsiasi cosa abbia un ticket e una scadenza. L'inquadramento più onesto è che una dipendenza runtime senza proprietario è al tempo stesso superficie di attacco non monitorata e un single point of failure non pianificato. Nessuno è reperibile per una connessione di cui non sa l'esistenza. Questo è l'argomento con cui ora ci presentiamo, perché è quello che sopravvive al confronto con una revisione della roadmap.