TL;DR
Il debito tecnico non è solo un fastidio per gli sviluppatori: è un rischio aziendale con interessi composti. Quando gli sviluppatori lasciano l’azienda, spesso si portano via il “perché” dietro al codice.
Il Clean Code non riguarda la perfezione: riguarda mantenere la conoscenza nel sistema, invece che nella testa di qualcuno.
This article is also available in English.
Poco tempo fa ho terminato il mio MBA e, guardando il mio lavoro anche da una prospettiva più business, sono arrivato a una conclusione interessante: sviluppatori e stakeholder hanno in realtà paura della stessa identica cosa, ma la descrivono con parole diverse.
Benvenuti nel Bus Factor.
Una piccola realizzazione durante l’MBA
Ho recentemente concluso il mio MBA e, tra fogli di calcolo, strategie e discussioni sul posizionamento di mercato, ho avuto una piccola illuminazione.
Mi sono reso conto che sviluppatori e business stakeholder spesso parlano lingue completamente diverse.
Noi sviluppatori parliamo di:
- Refactoring e pattern
- Debito tecnico
- Qualità del codice
Il lato business invece parla di:
- Mitigazione del rischio
- Turnover e ROI
- Scalabilità e produttività
Slide diverse, riunioni diverse, caffè diversi. Ma il punto è questo: in realtà abbiamo paura della stessa identica cosa.
Il Bus Factor
Il Bus Factor risponde a una domanda un po’ inquietante:
Quante persone possono lasciare il progetto prima che diventi un problema serio?
Se la risposta è una, ho una brutta notizia per te. Il tuo progetto ha un Bus Factor di 1 e la tua azienda sta praticamente gestendo una situazione di ostaggio software.
Questo succede più spesso di quanto tendiamo ad ammettere.
Un solo sviluppatore sa:
- Come funziona davvero il flusso di autenticazione
- Perché la logica di fatturazione richiede tre tentativi e una preghiera silenziosa al server
- Cosa ci fa ancora lì quell’"hack temporaneo" del 2019
E all'improvviso quello sviluppatore se ne va.
Nuovo lavoro.
Nuova città.
Magari un allevamento di pecore in Nuova Zelanda.
E così, all'improvviso...
l’azienda perde letteralmente una parte del suo cervello.
Amnesia aziendale
La Corporate Amnesia si verifica quando gli sviluppatori lasciano l’azienda portando con sé la conoscenza istituzionale:
- Contesto: perché è stata scelta quella tecnologia o quell’architettura
- Vincoli: trappole nascoste e aree fragili del codice
- Trade-off: compromessi e decisioni prese nel tempo
Anche la migliore documentazione può diventare obsoleta se non viene aggiornata costantemente.
Se il codice assomiglia a un museo di spaghetti sperimentali, tutta quella conoscenza si diluisce o scompare. Il prodotto esiste ancora, ma nessuno capisce davvero come funzioni.
E questo non è solo un problema tecnico, è un rischio economico serio.
Il fantasma degli sviluppatori del passato
Ogni sviluppatore ha vissuto questo momento.
Apri un file.
Scorri.
E scorri ancora.
Poi lo trovi: un useEffect() da 500 righe, senza commenti, con variabili chiamate temp, data2 e finalFinalVersion.
Controlli la cronologia Git.
L’autore? Ha lasciato l’azienda due anni fa. Forse ora alleva pecore in Nuova Zelanda.
Stai guardando una casa infestata di codice: troppo rischiosa da cancellare, impossibile da modificare con sicurezza.
Questo è il Fantasma degli Sviluppatori del Passato, e costa all’azienda migliaia di euro in produttività persa ogni giorno.
Clean Code come trasferimento di conoscenza
È qui che Clean Code cambia prospettiva.
Il Clean Code non è estetica: è comunicazione strategica.
Quando il codice è pulito, la conoscenza rimane nel sistema anche quando le persone se ne vanno. Ogni sviluppatore futuro può capire:
- Cosa fa il codice
- Perché esiste
- Come interagisce con il resto del sistema
senza fissare un incontro con esperti di archeologia.
Prendiamo questo esempio:
❌ Il modo criptico
function processData(d){
let t = d.filter(x => x.a)
let r = []
for(let i=0; i<t.length; i++){
if(t[i].b > 10){
r.push(t[i])
}
}
return r
}
✅ Il modo chiaro
function getActiveUsersWithHighScore(users) {
const ACTIVE_THRESHOLD = 10;
return users
.filter(user => user.isActive)
.filter(user => user.score > ACTIVE_THRESHOLD);
}
La logica è la stessa, ma la seconda versione comunica chiaramente l’intento. La conoscenza rimane nel codice, non solo nella testa di uno sviluppatore.
Il refactoring come assicurazione
Una delle frasi più comuni nelle aziende è:
"Non abbiamo tempo per fare refactoring"
Ma da una prospettiva aziendale, la vera domanda dovrebbe essere un'altra:
"Quanto ci costerà quando nessuno capirà più questo codice?"
Ogni ora spesa per trasformare una funzione Frankenstein in qualcosa di leggibile non è tempo sprecato.
È un investimento in:
- Velocità di onboarding: i nuovi sviluppatori diventano produttivi in giorni, non mesi
- Autonomia del team: chiunque può lavorare su qualsiasi parte del sistema
- Resilienza: quando qualcuno lascia l’azienda, il progetto sopravvive
In altre parole: il refactoring è letteralmente un'assicurazione contro l'amnesia aziendale.
Il codice è documentazione
Quando è scritto bene, il codice è la miglior documentazione possibile. Nomi chiari, funzioni piccole e architetture comprensibili preservano la conoscenza.
A differenza della documentazione statica, il codice pulito non diventa obsoleto per abbandono: evolve insieme al sistema.
Clean Code nell'era dell'IA
Oggi stiamo entrando in una nuova fase dello sviluppo software.
Gli strumenti di IA, come gli assistenti al codice, possono generare funzioni, componenti e persino interi moduli in pochi secondi.
Questo cambia la produttività, ma aumenta anche la posta in gioco per la qualità del codice.
Se l'IA genera codice su un'architettura disordinata, semplicemente accelera il caos, ma quando la base di codice è pulita e ben strutturata, l'IA diventa incredibilmente potente:
- comprende l'architettura più velocemente
- genera suggerimenti migliori
- riduce i tempi di sviluppo senza aumentare la complessità
In altre parole, il codice pulito diventa la base per un efficace sviluppo assistito dall'IA.
Un codice scadente rallenta gli esseri umani e un codice scadente rallenta anche l'IA.
Messaggio chiave
Se c’è una sola cosa da ricordare è questa:
Il Clean Code non riguarda l’eleganza: riguarda la memoria organizzativa.
Più a lungo vive un progetto, più questo diventa importante.
Pensiero finale
Dopo il mio MBA, una cosa è diventata molto chiara: il Clean Code è una strategia aziendale. Protegge dalla perdita di conoscenza, riduce l’attrito nell’onboarding e rende i team più resilienti ai cambiamenti.
Dato che gli sviluppatori cambiano lavoro molto più spesso di quanto il codice cambi repository, scrivere codice pulito è uno degli investimenti migliori che un’azienda possa fare.
Una domanda per te
Quanta parte del tuo sistema vive:
- Nel codebase
- Nella testa di qualcuno?
Condividi la tua esperienza nei commenti!
Top comments (1)
Un aspetto che non ho approfondito a fondo nell'articolo è questo:
Anche quando uno sviluppatore scrive codice eccellente, il suo abbandono ha comunque un costo.
L'assunzione richiede tempo.
L'inserimento richiede tempo.
La comprensione dell'architettura richiede tempo.
Il codice pulito non elimina questo problema, ma ne riduce il raggio d'azione.
Il vero obiettivo è garantire che la conoscenza viva all'interno del sistema, non solo nella mente di qualcuno.
Sono curioso di sentire la tua esperienza: