L'espressione «debito tecnico» è stata introdotta da Ward Cunningham per spiegare a chi non programma una dinamica familiare a ogni sviluppatore. Quando si sceglie una soluzione rapida invece di una ben strutturata, si ottiene un vantaggio immediato, come un prestito. Ma da quel momento si pagano gli interessi: ogni modifica successiva in quella zona del codice costa un po' di più. Se il debito non viene mai ripagato, gli interessi crescono fino a rallentare tutto il lavoro.
Non tutto il debito è un errore
La metafora è utile proprio perché un debito, di per sé, non è negativo. Un'azienda può indebitarsi consapevolmente per cogliere un'opportunità. Allo stesso modo, un team può scegliere una soluzione provvisoria per rispettare una scadenza importante o per verificare rapidamente se un'idea interessa agli utenti.
Una distinzione utile, proposta da Martin Fowler, incrocia due domande: il debito è stato contratto consapevolmente o per inesperienza? E con prudenza o con leggerezza?
| Con leggerezza | Con prudenza | |
|---|---|---|
| Consapevole | «Non abbiamo tempo per la progettazione» | «Rilasciamo ora e sistemiamo dopo il lancio» |
| Inconsapevole | «Cos'è la separazione dei livelli?» | «Ora abbiamo capito come andava fatto» |
L'ultima casella è inevitabile: lavorando su un sistema si impara, e col senno di poi si vede una struttura migliore. Il problema non è avere debito, ma non saperlo o non gestirlo.
Da dove nasce
Le fonti più comuni:
- scorciatoie sotto pressione: codice duplicato invece di una funzione condivisa, valori scritti direttamente nel codice, casi limite ignorati;
- assenza di test: ogni modifica diventa rischiosa, quindi si evita di migliorare il codice;
- dipendenze non aggiornate: librerie ferme da anni, il cui aggiornamento diventa sempre più difficile e rischioso;
- requisiti cambiati: il codice era adatto al problema di due anni fa, non a quello di oggi;
- conoscenza persa: chi aveva scritto il modulo non c'è più e nessuno osa toccarlo.
I segnali d'allarme
Il debito tecnico raramente si vede guardando il codice una volta. Si riconosce dai suoi effetti sul lavoro quotidiano:
- modifiche che dovrebbero richiedere un'ora ne richiedono un giorno;
- le correzioni di un bug ne causano altri in zone apparentemente non collegate;
- ci sono parti del sistema che tutti evitano di modificare;
- i nuovi membri del team impiegano settimane a diventare produttivi su un certo modulo;
- le stime diventano sempre meno affidabili, perché nessuno sa cosa si nasconde dietro una modifica.
Renderlo visibile
Un debito che esiste solo nella testa degli sviluppatori non può essere gestito. Il primo passo è registrarlo. Un approccio pratico:
- creare voci specifiche nel sistema di tracciamento del lavoro, con un'etichetta dedicata;
- per ogni voce, descrivere il problema, la zona interessata e soprattutto il costo che produce: «ogni nuovo metodo di pagamento richiede modifiche in cinque file diversi e circa tre giorni di test manuali»;
- stimare in modo grezzo lo sforzo per risolverlo.
Il costo è la parte più importante, perché è ciò che permette di parlare con chi decide le priorità. Un responsabile di prodotto difficilmente approverà «riscrivere il modulo pagamenti perché è brutto», ma capirà benissimo «possiamo ridurre da tre giorni a mezzo i tempi per aggiungere un metodo di pagamento».
Come ripagarlo
Fermare lo sviluppo per mesi per "ripulire tutto" è raramente possibile e spesso controproducente. Funzionano meglio strategie continue:
- regola del campeggiatore: ogni modifica lascia la zona toccata un po' più pulita;
- quota fissa: una parte stabile del tempo di ogni ciclo di lavoro dedicata al debito;
- ripagare dove si lavora: dare priorità al debito nelle zone che verranno modificate presto, perché è lì che gli interessi si pagano;
- lasciare stare il resto: un modulo brutto ma stabile, che nessuno tocca da anni, non genera interessi. Migliorarlo ha poco valore.
L'ultimo punto è controintuitivo ma fondamentale. Il debito va misurato in base all'attrito che genera, non all'estetica del codice.
Evitare di accumularne di nuovo
Alcune pratiche limitano il debito alla fonte: test automatici obbligatori, revisione del codice, aggiornamento regolare delle dipendenze in piccoli passi, e soprattutto l'abitudine di registrare subito le scorciatoie prese consapevolmente. Un commento nel codice con un riferimento alla voce di tracciamento costa pochi secondi e impedisce che la soluzione provvisoria diventi permanente per dimenticanza.
In sintesi
- Il debito tecnico è il costo futuro delle scorciatoie: si paga in interessi a ogni modifica.
- Non tutto il debito è un errore; il problema è non riconoscerlo e non gestirlo.
- Si riconosce dagli effetti: modifiche lente, bug a catena, zone che nessuno vuole toccare.
- Registralo descrivendo il costo che produce, così da poterne discutere le priorità.
- Ripagalo in modo continuo, partendo dalle zone del codice che cambiano più spesso.
