Fin da quando ho iniziato a lavorare ho sentito parlare di “debito tecnico”. Al lavoro recentemente abbiamo anche creato una board dedicata esclusivamente al tracciamento del debito tecnico.
Ma che cos'è il debito tecnico? Pur non avendo mai approfondito il concetto è facile capire a grandi linee di cosa si tratta: sono tutte quelle cose che uno lascia indietro oggi per poter rilasciare prima il software sapendo che prima o poi sarà necessario ritornarci sopra.
In realtà la metafora del debito tecnico è un po' più articolata di così e oggi ho approfittato di un giorno di ferie per studiare meglio la questione analizzando le parole del leggendario Martin Fowler.
Prima di cominciare mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!
Definizione #
Il debito tecnico è una metafora concepita da Ward Cunningham che assimila la complessità di un software ad un debito finanziario e lo sforzo necessario ad aggiungere una nuova funzionalità all'interesse pagato sul debito.
Ogni riga di codice scritta, ogni libreria installata nel progetto incrementa il livello di complessità generale al progetto andando ad incrementare il debito tecnico.
Esattamente come accade per i debiti finanziari, la scelta migliore è pagare gradualmente in "comode" rate mensili.
La forza di questa metafora consiste nel rendere evidente anche a chi non è un ingegnere del software come anche le attività di refactoring del codice, pur non portando nuove funzionalità al progetto, sono necessarie a "ripagare" la quota del debito.
Ogni volta che è necessario aggiungere una nuova funzionalità al progetto sarebbe buona norma investire del tempo per ristrutturare il codice esistente. Chiaramente in questo modo si otterrebbero dei cicli di sviluppo più lunghi. Tuttavia, qualora dovesse capitare di lavorare nuovamente sulla stessa porzione di codice il lavoro potrebbe procedere in modo molto più spedito avendo già pagato la quota di debito.
Se invece si decidesse di non pagare periodicamente le quote di debito tecnico si finirebbe per avere cicli di sviluppo molto rapidi all'inizio ma, mano a mano che il debito si accumula, i tempi di sviluppo si estenderebbero sempre di più fino ad arrivare al fatidico momento in cui la complessità del software è così alta che non è più possibile sviluppare nuove funzioni in tempi ragionevoli. Quando si arriva in questa situazione, quello che accade solitamente è che si getta la spugna ed è necessario riscrivere da capo il software.
Posso pagare il debito tecnico in stelline?
Una delle principali differenze con i debiti finanziari invece è che, contrariamente ai debiti finanziari in cui l’interesse da pagare è sul totale, sui debiti tecnici il costo da pagare è dipendente dalla porzione di codice. In un software possono esistere parti di codice da incubo con un debito tecnico altissimo ma che non tocca nessuno e quindi un interesse bassissimo e parti di codice che invece sono modificate frequentemente e che quindi pur avendo dei piccoli debiti hanno degli interessi stellari.
TIPOLOGIE DI DEBITO #
A seconda di come si affronta il debito tecnico è possibile individuare due classificazioni del debito. Una basata sul rischio (prudente/imprudente) e una basata sulla coscienziosità con cui si protrae il debito (volontario/involontario). Vediamo di seguito come si combinano le due classi:
- DEBITO VOLONTARIO E PRUDENTE: nello sviluppo di un progetto è ammissibile accettare di fare del debito per concentrarsi sulle cose urgenti. L’importante è sapere che il debito fatto oggi tornerà a chiederci gli interessi domani.
- DEBITO VOLONTARIO E IMPRUDENTE: questo forse è il caso peggiore. So di indebitarmi pur di consegnare il software ma faccio finta che stia andando tutto bene trascurando completamente le conseguenze di tale indebitamento.
- DEBITO INVOLONTARIO E IMPRUDENTE: questo in genere accade agli sviluppatori alle prime armi che non conoscono il concetto di debito tecnico e non si rendono conto che cattive scelte fatte in fase di progetto li perseguiteranno in futuro.
- DEBITO INVOLONTARIO E PRUDENTE: Molto spesso accade che nonostante si abbiano seguito perfettamente le migliori best-practices ci si rende conto che se si fosse utilizzato quel design pattern o quell'altra architettura il codice sarebbe stato sicuramente migliore (in termini di complessità).
Queste combinazioni possono essere riportate in un grafico fatto nel seguente modo:
Il fatto che ogni progetto finisca per avere del debito tecnico però non deve essere preso come scusa per trascurare la qualità del codice. Aggiungere codice di scarsa qualità ad un progetto già indebitato fino al collo o scordarsi di pagare le rate degli interessi non può che peggiorare la situazione arrivando a rendere impossibile lo sviluppo di nuove funzionalità.
D’altro canto, un debito ben ragionato con piccole quote di interesse pagate regolarmente può permettere di accelerare il rilascio di nuove funzionalità.
Conclusioni #
Ogni volta che adottiamo una soluzione "quick and dirty" per risolvere un problema stiamo facendo debito. Ogni volta che trascuriamo di aggiornare le libreria del progetto stiamo facendo debito. Ogni volta che ci rendiamo conto che avremmo potuto semplificare il codice e non lo facciamo stiamo facendo debito.
Il debito tecnico quindi è un’ombra che che incombe su ogni sviluppatore. Può sembrare minacciosa ma il solo sapere che esiste può essere sufficiente per tenerla a bada.
Il debito tecnico di per sé non è malvagio. Avere un debito è normale per qualunque azienda si occupi di software. La cosa fondamentale da fare però è fare in modo che non raggiunga mai soglie troppo elevate e che le quote di interesse non schizzino alle stelle paralizzando completamente il progetto.
Come per i debiti finanziari la bravura sta nel ripagare il debito in piccole rate includendo sempre nella roadmap dei progetti del tempo da dedicare al refactoring del codice.
Se questo post ti è piaciuto e ti è stato utile ti invito ad iscriverti al mio canale Telegram. Se invece hai domande o vuoi lasciare un commento puoi contattarmi direttamente su Telegram o su Twitter. A presto!