Debito Tecnico #2: Da dove nasce

by Andrea Maioli on 22 gennaio 2013

La scorsa settimana abbiamo parlato di debito tecnico nell’ambito dello sviluppo di software, definendolo come quella parte di lavoro necessaria per completare le modifiche previste attualmente ma che non si può o non si vuole svolgere oggi, e che dovrà poi essere perfezionata o conclusa successivamente. In questo articolo vediamo da dove nasce il Debito Tecnico e quali sono le pratiche lavorative che ne causano maggiormente l’aumento. A tale scopo ragioniamo “per assurdo”, come dicono i matematici. Può esistere una metodologia organizzativa dello sviluppo di software che non crea debito tecnico? In teoria la risposta è positiva. È sufficiente che:

  1. Siano disponibili tutto il tempo e le risorse necessarie per analizzare e comprendere al 100% il processo che si deve informatizzare (debito per mancanza di analisi).
  2. Siano disponibili tutto il tempo e le risorse per scrivere il codice in modo perfettamente coerente con le best practices delle varie tecnologie utilizzate (debito per mancanza di best practices).
  3. Siano disponibili tutto il tempo e le risorse per modificare il codice esistente in modo che sia perfettamente integrato con il nuovo codice creato. Questo richiede anche una perfetta comprensione del codice esistente (debito per mancanza di integrazione).
  4. Siano disponibili tutto il tempo e le risorse per creare una suite di test automatici e di integrazione per testare ad una ad una le varie caratteristiche del codice scritto (debito per mancanza di suite di test).
  5. Siano disponibili tutto il tempo e le risorse per scrivere la documentazione tecnica di supporto per le future modifiche alla codebase (debito per mancanza di documentazione tecnica).

Leggendo questa lista, è abbastanza evidente che è praticamente impossibile non creare una gran quantità di debito tecnico. In particolare si incrementa sempre più al crescere della complessità del software a causa del terzo punto, e al variare delle tecnologie in funzione del secondo punto. La situazione che fa crescere maggiormente il debito tecnico è rappresentata dalle piccole modifiche ad un software molto complesso. In tale situazione, infatti, non si riesce a giustificare la mole di lavoro necessaria per completare la modifica senza creare debito, e così nascono le cosiddette correzioni a cerotto, che si spera resistano anche nel futuro. Nella prossima puntata vedremo come si può gestire il debito tecnico e come la programmazione relazionale di Instant Developer può rappresentare un’arma formidabile per ottenere questo obiettivo. Nel frattempo, perché non provate a farvi un’idea di quanto debito tecnico avete accumulato?

In questa serie:

Image: On Space Time Foam by Tomás Saraceno

{ 1 comment… read it below or add one }

1 Mauro Marini 22 gennaio 2013 alle 15:06

Molto interessante e vera la classificazione dei debiti.
Non so se verrà trattato nella prossima puntata, ma sarebbe molto utile un capitolo del prossimo manuale sulla rifattorizzazione del codice, con consigli e best practice sui casi più frequenti. Ad esempio, come affrontare il cambiamento del nome di una tabella nel DB e gestire gli effetti collaterali nel codice. Da poco ho notato che Microsoft ha introdotto un parametro di configurazione del designer in SQLServer Studio Manager che quando si accorge essere necessario rigenerare una tabella a causa di una modica, la impedisce e basta. Bel modo elegante di affrontare il problema!

Ora non resta che aspettare la prossima puntata e togliere il cerotto…

Leave a Comment

Previous post:

Next post: