Debito tecnico: definizione e soluzioni

Che cos’è il debito tecnico

Il termine debito tecnico in informatica si riferisce alle conseguenze di azioni di sviluppo software che intenzionalmente o meno prioritizzano il valore del cliente e/o gli obblighi di progetto (su tutti le deadline) rispetto a implementazioni e considerazioni tecniche più approfondite. In poche parole, si tratta di codice scritto che richiederà più ore di lavoro per essere sistemato.

L’accumulo del debito non è da ricondurre alla scrittura di codice di pessima qualità, ma alle dinamiche dei progetti software dove potrebbe esserci un disallineamento tra il lavoro del gruppo di sviluppo e i bisogni del business. Per evitare l’accumulazione del debito quindi, occorre sottoporre sistematicamente il codice a un’azione di refactoring (oltre a porre particolare attenzione alla fase di progettazione).  Il termine “debito” non è casuale: con il passare degli anni, gli interessi aumentano, nel senso che è sempre più difficile mettere le mani sul codice e modernizzarlo.

Il debito si accumula anche a causa della rapidità dei cambiamenti tecnologici: quello che abbiamo sviluppato può diventare obsoleto molto velocemente e non corrispondere più ai bisogno del business. Proprio per questo, un lavoro di refactoring costante è fondamentale.  Spesso, questo tipo di attività non viene portata avanti per diversi motivi:

• il team di sviluppo è spesso sottoposto a deadline stringenti che non permettono loro di fare un lavoro pulito fino dall’inizio poiché si va a prediligere la funzionalità sulla qualità;
• il budget potrebbe risultare scarso o comunque non sufficiente a coprire le spese del refactoring.

Strategie per rilevare e ridurre il technical debt

Come si può ridurre il debito tecnico? Si possono innanzitutto implementare delle best practice per prevenirlo:

• test automatici per rilevare eventuali bug o errori nel codice;
• organizzare la progettazione del codice nei minimi dettagli, utilizzando anche dei software appositi.

La verità è che il debito è una conseguenza fisiologica della scrittura del codice. Come capire quando il debito può rappresentare un problema strutturale e limitativo dell’agilità del business? Un debito tecnologico importante comporta costi elevati e rallenta il time-to-market. È quindi fondamentale monitorare diversi parametri che vanno a identificare lo stato del debito:

• Percentuale di code coverage totale e per funzione: una percentuale in calo è un segnale di allarme che indica un debito tecnologico in crescita;
• Numero di build CI o CD fallite: se il numero di build CI/CD fallite aumenta, è un forte indicatore di instabilità nella tua base di codice;
• Numero di bug settimanali/ mensili: se questo aumenta, indica una diminuzione della qualità del codice;
• Velocità nell’avvio di una nuova funzionalità;
• La misurazione di metriche non funzionali come le prestazioni delle applicazioni, l’esperienza utente o la perdita di compatibilità è solida indicatrice di un aumento del debito tecnico.

Segnali chiari di technical debt sono:

• i progetti si bloccano perché gli sviluppatori non hanno informazioni dettagliate sulla base di codice;
• 23-42% del tempo dei developer è sprecato a causa del debito;
• emergono bug difficili da correggere a causa della complessità o della mancanza di documentazione;
• correzioni di bug creano nuovi bug o un costante degrado delle prestazioni;
• se l’azienda deve affrontare più del 15% di attività non pianificate, questo è probabilmente a causa del debito.

La riduzione del technical debt deve partire innanzitutto dalla comprensione della sua origine e dall’analisi delle metriche per pianificare il lavoro.

Cosa fare quindi per ridurre il debito tecnico?

1. È importante scegliere un’architettura software scalabile come quelle basate su microservizi/container per permettere un’evoluzione del software continua;
2. È necessario rendere attività di routine la revisione del codice: questo migliora la qualità del codice e riduce il debito;
3. Utilizzare gli strumenti di testing automatico per il monitoraggio costante dell’applicativo, durante il suo intero ciclo di vita;
4. Tenere traccia: mantenere un registro continuo delle modifiche in un repository condiviso da un team. In questo modo, se si verifica un problema, possiamo facilmente risalire alla sua origine;
5. Ridurre il debito tecnico gradualmente, dando priorità a determinate parti di codice più critiche.

Debito tecnico e analisi automatica del codice: Codescene

Per rilevare il debito tecnico più velocemente e per individuare dove è necessario intervenire, un’azienda di consulenza informatica deve necessariamente fornirsi di uno strumento automatico di analisi del codice. Non tutti gli strumenti però riescono a intercettare i diversi livelli di gravità: da questo punto di vista, Codescene è la soluzione open-source che permette di rilevare gli hotspot ovvero le parti di codice ad alto interesse di debito, quelle sulle quali è più urgente intervenire per ridurlo. Gli hotspot rappresentano in realtà dal 2 al 4% del codice, mentre il resto del debito di trova sulla coda e ha un bassissimo livello di interesse.

Per ottimizzare e velocizzare quindi la riduzione del debito è fondamentale intercettare questi hotspot e risolvere questi errori.

Una volta che CodeScene ha rilevato un hotspot, lo strumento fornisce una revisione automatizzata del codice che classifica ogni hotspot in base a gravità e stato del codice. Dando priorità al debito tecnico in testa alla curva, CodeScene suggerisce interventi con un reale ritorno sull’investimento.

Codescene può essere eseguito sia on-premise che in cloud e gli sviluppatori possono misurare l’impatto del loro codice prima che venga unito e agire per prevenire il debito tecnico prima che si verifichi. L’integrazione è automatizzata per GitHub, BitBucket, BitBucket Server, GitLab, Azure DevOps e Gerrit.