Vai al contenuto

Debito tecnico

Da Wikipedia, l'enciclopedia libera.

Il debito tecnico è una metafora inventata da Ward Cunningham per descrivere le possibili complicazioni che subentrano in un progetto, tipicamente di sviluppo software, qualora non venissero adottate adeguate azioni volte a mantenerne bassa la complessità. Analogamente a quanto avviene nel mondo finanziario, in cui per sanare un debito occorre pagarne anche gli interessi, lo sforzo per recuperare un progetto sviluppato senza una corretta metodologia può aumentare anche considerevolmente nel tempo, se non si interviene tempestivamente.

Le cause più comuni[1] (o loro combinazione) che possono portare ad un debito tecnico sono:

  • Esigenze di mercato, ossia l'urgenza di avere un prodotto da vendere prima possibile, quindi rilasciato prima che le dovute modifiche siano complete.
  • Mancanza di conoscenza del processo, in cui chi prende le decisioni è ignaro delle implicazioni sottostanti (o decide di ignorarle).
  • Mancanza di disaccoppiamento, quando lo sviluppo delle componenti del programma avviene ignorando il paradigma di programmazione modulare o comunque senza l'intento di mantenere basso il legame di dipendenza tra i sottosistemi.
  • Assenza di procedure di test, che incoraggia correzioni di bug "al volo" che non contemplano possibili effetti secondari.
  • Assenza di documentazione, dove il codice viene sviluppato "a braccio", senza documentazione/specificazione dei requisiti. Il lavoro per produrre la suddetta documentazione a posteriori, e la necessaria verifica di corrispondenza con quanto già codificato, rappresenta un debito che occorre prima o poi saldare.
  • Mancanza di collaborazione, causa di degrado dell'efficienza del processo di sviluppo. Un'altra motivazione potrebbe ascriversi ad un affiancamento dei principianti insufficiente o assente da parte delle figure professionali con maggior esperienza.
  • Mancanza di conoscenza, quando il programmatore semplicemente non ha le competenze per scrivere del codice di qualità.
  • Introduzione di dipendenze senza criterio, quando lo sviluppatore introduce nuove tecnologie con costi impliciti di mantenimento (di licenza, di know how, di interoperabilità, di manutenibilità, di supporto esterno) per risolvere "facilmente" i problemi.

In particolare nelle piccole aziende di software le cause più frequenti sono la pressione aziendale (l’urgenza di avere qualcosa da consegnare per il traguardo il prima possibile), la definizione iniziale incompleta (quando lo sviluppo inizia prima di qualsiasi fase di progettazione o comunque quando i requisiti devono ancora essere definiti durante lo sviluppo) e le modifiche alle specifiche dell’ultimo minuto[2].

Quadrante del Debito Tecnico
Avventato Prudente

Volontario
"Non abbiamo tempo per progettare" "Dobbiamo rilasciare ora ed occuparci delle conseguenze (più avanti)"

Involontario
"Cos'è il Layering?" "Ora sappiamo come avremmo dovuto farlo"

Occorre tener conto della distinzione tra tipi di debito tecnico. Martin Fowler nel suo blog di discussione sul tema dello sviluppo, individua il cosiddetto "Quadrante del debito tecnico"[3], distinguendo tra quattro tipi di debito in base a due categorie dicotomiche.

La prima categoria individua la contrapposizione tra debito Avventato e Prudente, mentre la seconda dicotomia è tra debito tecnico Volontario e Involontario.

L'Asse Orizzontale: "Avventato vs. Prudente" (Come viene gestito il debito tecnico). Riguarda la prudenza nella valutazione dei rischi: Impulsività vs. Pensiero Strategico

Asse Verticale: "Volontario vs. Involontario" (Quanto è intenzionale il debito tecnico). Riguarda la conoscenza tecnica e la consapevolezza: Consapevolezza vs. Ignoranza.

Spiegazione dei Quadranti

[modifica | modifica wikitesto]

1. Avventato-Volontario

[modifica | modifica wikitesto]
  • Esempio: "Non abbiamo tempo per il design."
  • Il team sceglie consapevolmente di accumulare debito tecnico senza valutarne le conseguenze.
  • Porta spesso a un codice mal strutturato, difficile da mantenere e con costi futuri elevati.

2. Prudente-Volontario

[modifica | modifica wikitesto]
  • Esempio: "Dobbiamo rilasciare ora e affrontare le conseguenze dopo."
  • Il team decide consapevolmente di accumulare debito tecnico, ma pianifica di risolverlo successivamente.
  • Spesso è una scelta strategica per rispettare scadenze aziendali, con un piano di refactoring già in mente.

3. Avventato-Involontario

[modifica | modifica wikitesto]
  • Esempio: "Cos’è il layering?"
  • Il team non si rende conto di accumulare debito tecnico perché non ha le conoscenze adeguate sulle buone pratiche di sviluppo.
  • È il tipo di debito tecnico più pericoloso, perché porta a un codice caotico e insostenibile.

4. Prudente-Involontario

[modifica | modifica wikitesto]
  • Esempio: "Ora sappiamo come avremmo dovuto farlo."
  • Il team ha fatto del suo meglio, ma con il tempo ha capito un approccio migliore per progettare il software.
  • Questo tipo di debito tecnico è naturale e inevitabile, perché la conoscenza cresce durante lo sviluppo.
  1. ^ (EN) Hiren Dhaduk, Tech debt: How to Manage Debts for your Software Development?, su Simform - Product Engineering Company, 11 ottobre 2022. URL consultato il 1º giugno 2023.
  2. ^ Il debito tecnico nelle piccole aziende di software, su annibali.eu. URL consultato il 14 giugno 2020.
  3. ^ Martin Fowler, su martinfowler.com. URL consultato il 19 novembre 2014.
  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica