Gestione del technical debt

 Technical debt

Il peso del technical debt

Introduzione

Il mondo è in continua evoluzione e con esso cambiano i requisiti e le funzionalità che si richiedono ai software. La manutenzione del software occupa l'80-90% della vita di un software, a volte anche più. 

Le continue modifiche al software deteriorano la qualità del software e il suo technical debt. Questo nome, introdotto da Ward Cunningham, rappresenta il costo aggiuntivo delle manutenzioni successive dovuto a scelte non ottimali effettuate. 

Una manutenzione non attenta alla limitazione del technical debt fa si che i costi delle manutenzioni successive aumentino sempre più sino a quando diventa più economico scrivere un nuovo software che manutenere il vecchio, con costi enormi ove si tratti di software di grande complessità.

E' dunque essenziale prendere coscienza dei motivi per cui nasce il technical debt e sia riconoscere le varie forme in cui esso si presenta, al fine di poter sia evitarlo che correggerlo prima che sia troppo tardi.

Modelli di processo per la manutenzione

Distinguiamo principalmente due modalità di manutenzione: il quick fix e l'iterative enhancement.

Quick Fix

Sono effettuate modifiche al codice cercando di correggere esattamente l'errore che si presenta o implementando la funzionalità mancante col minore sforzo possibile in termini di tempo. Le conseguenze tipiche di questa modalità sono il degrado della struttura e della qualità del codice, e una documentazione che di solito non viene aggiornata o viene aggiornata a posteriori.

E' ammissibile se c'è un difetto serio nel software che deve essere corretto con estrema urgenza, perché i suoi effetti collaterali stanno creando seri problemi agli utenti. Ma anche in quei casi dovrebbe poi essere seguito da una revisione ed eventuale integrazione della modifica effettuata.

Studi condotti su molteplici progetti indicano in questo modello di processo la principale causa di  un rapido aumento del technical debt.

Iterative Enhancement

Si effettua una attenta analisi dei requisiti sulla modifica da implementare, si valutano le possibili soluzioni e si sceglie la migliore in base a dei criteri ben chiari, quali possono essere il maggiore o minore impatto sul sistema, l'impatto sulle prestazioni, l'aumento di complessità della struttura, la semplicità di interfaccia. E' più lento e costoso sul breve termine del quick fix, ma nel lungo termine ove utilizzato con costanza, fa si che i tempi di manutenzione non "esplodano" dopo un certo numero di manutenzioni. Prevede che la documentazione sia sempre aggiornata, insieme agli unit test e ai test di integrazione.

Cause del debito tecnico

Considerato che il debito tecnico si crea con la manutenzione, è ovvio che la qualità della manutenzione sia essenziale, quindi quali motivi possono concorrere a trascurare questo aspetto?

Senz'altro la pressione dei clienti per ricevere molte nuove funzioni o l'evolversi dell'ambiente circostante con le sue regole, e questo può indurre il manager a richiedere più modifiche nello stesso lotto di richiesta. D'altra parte i progettisti e gli sviluppatori, a loro volta pressati sui tempi di consegna, possono comprimere o saltare alcune fasi previste nel normale modello di sviluppo (ad esempio non analizzare l''impatto o ignorare i vari use cases, o non scrivere gli unit test...) per soddisfare le richieste in meno tempo, trascurando quindi gli effetti a lungo termine del debito tecnico.

Ma oltre all'ignoranza e alla non consapevolezza su cosa comporti il debito tecnico, la comunità degli sviluppatori ha individuato altre cause:

• date di consegna da rispettare, e questo effetto aumenta man mano che la data diviene più prossima, causando una maggiore disattenzione verso i paradigmi basilari per la progettazione e lo sviluppo
• mancanza di buoni progettisti, che quindi non seguano i principi fondamentali e le best practices
• non conoscenza delle corrette modalità di applicazione del refactoring e sulla qualità della struttura del software 

Tipologie di debito tecnico

• Codice: Parametri di qualità non rispettati (es. eccessiva complessità ciclomatica, eccessivo accoppiamento, mancanza di coesione...), stili di codice non omogeneo
• Progettazione: violazione dei principi della software engineering, quali l'information hiding, e scarsa attenzione alla successiva manutenibilità
• Test: mancanza di procedure di test automatico e copertura con i test dei vari use case
• Documentazione: insufficiente o non aggiornata documentazione sulle varie fasi di sviluppo

Conseguenze del debito tecnico

Ci sono diversi aspetti del software che vengono seriamente danneggiati dal debito tecnico:

• Affidabilità, la capacità di essere eseguito senza incorrere in bug
• Testabilità, il corredo di test e la possibilità di verificarne il funzionamento
• Riusabilità delle componenti, ossia la possibilità di non disseminare di oggetti simili il sistema, per una cattiva progettazione degli stessi
• Estendibilità, la facilità con cui ad un software si possono aggiungere nuove funzionalità senza doverlo modificare radicalmente
• Modificabilità, la facilità con cui è possibile cambiare una funzionalità senza doverlo modificare radicalmente, ossia con un impatto limitato sul codice esistente
• Leggibilità, la semplicità con cui è possibile, leggendo la documentazione ed il codice, comprenderlo e riuscire a manutenerlo.

Conclusioni

Se un software fosse rilasciato e poi non più manutenuto, non avrebbe senso preoccuparsi del debito tecnico. Ma per i software utilizzati per vari anni e di cui sono rilasciati, per vari motivi, degli aggiornamenti periodici, la gestione del debito tecnico assume un'importanza vitale ai fini della possibilità che il software continui ad esistere.

Nei prossimi articoli esamineremo alcuni "design smells" per imparare a riconoscere gli errori introdotti dal technical debt e vedremo come affrontarli e risolverli.

bibliografia

Refactoring for Software design smells  Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma