Il tuo codice nasconde un patrimonio di conoscenza che nessuno sfrutta
Ecco qualcosa che dovrebbe far venire i brividi a ogni CTO e lead developer: la comprensione più sofisticata del tuo business potrebbe risiedere solo nel codice di produzione.
Una ricerca recente del team di ServiceMatch esplora un'idea provocatoria. Sostengono che i sistemi software maturi non sono semplici strumenti che fanno funzionare il business — sono rappresentazioni eseguibili di tutto ciò che l'organizzazione ha imparato su quel business. Il problema? Quella conoscenza si nascondeva in piena vista, bloccata dentro repository che venivano letti solo da compilatori e (ogni tanto) da esseri umani.
Il Mito della Documentazione
Ci siamo passati tutti. Un nuovo sviluppatore entra nel team e gli viene consegnata una montagna di pagine Confluence, archivi di decisioni architetturali e voci di Wiki. "Questo ti porterà up to speed," dice qualcuno con ottimistica certezza.
Non sarà così.
La documentazione cattura quello che qualcuno ha pensato valesse la pena scrivere, in un momento che potrebbe risalire a anni fa. Perde i casi limite. Perde le discussioni avvenute nelle riunioni che hanno plasmato le decisioni. Perde la logica di business che si è evoluta attraverso migliaia di commit, ognuno dei quali ha lottato con uno scenario reale.
Secondo l'argomento di Peter Naur del 1985 (sì, lo stesso Naur che ci ha dato la forma di Backus-Naur), la documentazione dei programmi non potrà mai catturare completamente la "teoria" dietro un sistema. La comprensione reale vive nelle teste delle persone. Quando quelle persone se ne vanno, la teoria se ne va con loro.
Ma qui le cose si fanno interessanti.
L'AI Cambia il Problema del Lettore
L'argomento di Naur riguardava due tipi di lettori: i compilatori (che eseguono il codice senza capirlo) e gli umani (che lo capiscono lentamente e costosamente). L'impossibilità del revival della documentazione assumeva che non esistesse nessun altro tipo di lettore.
I large language model sono un terzo tipo di lettore. E sono sorprendentemente bravi a ricostruire le teorie implicite incorporate nel codice.
Il sistema ServiceMatch ne offre una prova convincente. La loro piattaforma CMDB codifica conoscenze di configuration management aziendale che riempirebbero volumi se fossero scritte in prosa. Ma ecco il punto — sono già scritte, solo non in prosa. Sono nel codice.
Consideriamo la loro logica di identity resolution. Invece di un saggio di un consulente su "come funziona l'identità dei dispositivi", hanno un file di configurazione con pesi: numero di serie (25), hostname (25), asset tag (25), indirizzo IP (20), indirizzo MAC (15). Più soglie di confidenza e regole di risoluzione conflitti. Ogni numero rappresenta una discussione vinta da qualcuno. Ogni tipo di conflitto rappresenta un incidente reale capitato da qualche parte.
Questo non è una descrizione della policy. Questa È la policy, che gira ogni notte contro gli estate aziendali reali.
Cosa Significa Per il Tuo Team
Per sviluppatori e leader tecnici, questa ricerca ha implicazioni pratiche:
Il tuo codice è documentazione che non hai mai mantenuto — e questo ha i suoi vantaggi. A differenza delle pagine wiki obsolete, il codice che gira in produzione viene costantemente validato. Se la documentazione è in disaccordo con il codice, è la documentazione ad avere torto.
Gli strumenti AI stanno migliorando nell'estrarre questa conoscenza. Stiamo andando verso un mondo dove chiedere a un'AI "come gestiamo i conflitti di identità dei dispositivi" potrebbe restituire non solo documentazione, ma il ragionamento effettivo codificato nei pesi e nelle soglie.
La conoscenza reale vive nei casi limite. I flussi principali sono di solito ben documentati. È la gestione speciale, le eccezioni, i casi edge risolti nel corso di anni che contengono la conoscenza istituzionale profonda.
Il Segnale di Allarme
C'è una corollary scomoda a tutto questo: se la tua logica di business è solo nel tuo codice, e il tuo codice ha scarsa copertura test, naming poco chiaro o struttura caotica, stai seduto su un mucchio di conoscenza quasi impossibile da estrarre.
Il team ServiceMatch ha scoperto che la loro affermazione — che "il repository basta" — si rompe in modi prevedibili. Il residuo tacito di Naur è reale. Alcuna conoscenza vive davvero solo nelle teste delle persone.
Ma la scoperta più forte è che nel codice sopravvive più di quanto pensassimo possibile. Il repository cattura molta più teoria di quanto la documentazione potrebbe mai fare — avevamo solo bisogno di un nuovo tipo di lettore per estrarla.
Cosa Fare Con Questo
Se sei una startup o un'azienda tech in crescita, ecco un framework per pensare a questo:
- Fidati del tuo codice più che dei tuoi docs quando i due sono in disaccordo
- Scrivi codice che documenta il suo ragionamento — nomi di variabili significativi, funzioni chiare, commenti che spiegano IL PERCHÉ, non solo COSA
- Tratta la configurazione come conoscenza istituzionale — quei pesi e soglie sono decisioni che vale la pena preservare
- Inizia a esplorare strumenti AI che possano interrogare il tuo codebase come fonte di conoscenza
Il codice che scrivi oggi è la conoscenza istituzionale di domani. Fai in modo che conti qualcosa.