Ridurre il Debito Tecnico un’Intenzionale con gli strumenti di Quality Management di Visual Studio

Abbiamo parlato più volte di Technical Debt all’interno dei nostri post, evidenziando come, se non gestito correttamente, possa portare in extremis alla necessità di riscrivere completamente un sistema software (Critical Mass of Software System: quando la qualità del software significa manutenibilità). Nel post “ALM, un approccio pratico alla gestione del Debito Tecnico” abbiamo anche visto come utilizzare una Clean Technical Debt Iteration (CTDi) tracciata in VSO/TFS per gestire e ridurre il debito tecnico accumulato.

E’ giunto ora il momento di vedere come essere proattivi, mettendo in campo quanto possibile per evitare la creazione del debito tecnico e ridurre gli interessi da pagare. Prima di vedere gli strumenti disponibili è utile soffermarci sulla terminologia, proponendo la tassonomia riportata nella figura seguente. 

technical debt taxonomy

Technical Debt Taxonomy

Esiste una verità difficilmente confutabile: per quanto vogliamo evitarlo, il nostro progetto avrà sempre un debito tecnico! Chiaramente, in questo caso, siamo nel campo dell’Unintentional Debt (Type 1), che è dettagliabile in due specifiche tipologie:

  • 1.A Naive Debt: questo debito deriva da cattive pratiche di sviluppo ed è quello su cui è possibile intervenire con maggior successo. Si pensi, ad esempio, ad un Team che non fa testing: un buon seminario su xUnit e l’utilizzo (eventuale e con parsimonia) del Gated check-in darà risultati lodevoli;
  • 1.B Unavoidable Debt: si tratta di debito ereditato su cui è difficile intervenire. Un esempio per tutti: una libreria sviluppata esternamente e utilizzabile solo as-is.

Dualmente all’Unintentional Debt è possibile identificare un “debito voluto” che indicheremo come Intentional Debt. Si tratta di una scelta dettata spesso da esigenze inderogabili e quasi sempre non tecniche, ad esempio: il Time-to-Market. Le afferenti tipologie di debito sono:

  • 2.A Short-term Debt, a sua volta diviso in:
    • 2.A.1 Identifiable significant shortcuts, ovvero il debito specificamente creato/accettato per raggiungere obiettivi strategici tramite tattiche di medio/breve termine. Si pensi alla necessità di procedere in parallelo sullo sviluppo e all’utilizzo temporaneo di fake library per realizzare una versione di supporto temporanea per il modulo che si sta realizzando, in attesa che quello definitivo sia ultimato;
    • 2.A.2 Identifiable tiny shortcuts, questo debito è assolutamente da evitare perché, nonostante sia creato per raggiungere uno specifico obiettivo di Program Level, ha degli altissimi costi di interesse, essendo sparso a macchia di leopardo. Esempi specifici sono: codice scritto frettolosamente, scarsa strutturazione del modello di dominio, ecc…
  • 2.B Long- term Debt, questo debito è legato ad obiettivi strategici di lungo/medio termine, supportati da una specifica visione. Rientra in questo ambito, ad esempio, la scelta voluta di creare una soluzione per uno specifico ambiente di erogazione anche se la relativa nuova versione è in fase di rilascio e potrebbe non essere correttamente supportata.

Nella tassonomia che abbiamo presentato, è presente anche il Non-Debt che non va interpretato come l’assenza di debito tecnico, piuttosto è da intendersi come classificazione di specifiche attività che avvengo durante il ciclo di delivery. Prendiamo la decisione di posticipare lo sviluppo di una Feature alla successiva release: questo non crea un “debito tecnico”, sia nel caso in cui la scelta è frutto di una discussione con il key-stakeholder, sia che lo sia unilateralmente (in tale scenario il prodotto manca di una funzionalità nel suo insieme ma non è stato aggiunto o creato debito tecnico afferente).

Proseguiamo rispondendo ora alla domanda fondamentale: quando e come pagare gli interessi associati al debito tecnico?

Qui il dualismo con il “debito finanziario” è decisamente più sfumato, perché non sempre è necessario pagare il debito tecnico: se si è in presenza di un software che sta per raggiungere la fine del suo naturale ciclo di adozione, non ha alcun senso investire su di esso e, quindi, pagare il debito tecnico accumulato.

Se, invece, ciò è necessario, è possibile adottare diverse tecniche: da quella citata all’inizio dell’articolo, e spiegata nel post specifico, piuttosto che il pagamento alla successiva iterazione con l’inserimento nell’Iteration Backlog dei Work Item relativi. Ogni azienda ed ogni Team hanno un approccio specifico, esattamente come ogni azienda gestisce in modo proprio il debito finanziario.

Come evidenziato, l’ambito 1.A è quello in cui è possibile intervenire in maniera più efficace. In particolare, Visual Studio 2013 mette a disposizione tutta una serie di strumenti pensati proprio per aumentare la qualità della propria soluzione:

  • Code Analysis, consente di verificare l’aderenza del codice alle regole e best practice selezionate;
  • Code Metrics, consente di analizzare il codice alla ricerca delle aree di maggior complessità e di difficile manutenzione;
  • Code Clone Analysis, consente di ricercare il codice clonato/simile, anche parziale, indipendentemente da alcuni aspetti caratterizzati (es: nome variabile). Molto utile per in caso di utilizzo intensivo di copia e incolla… ogni commento è superfluo, ovviamente!
  • CodeLens, introdotto con Visual Studio 2013, consente di visualizzare direttamente sul codice corrente informazioni relative (es: test superati, riferimenti diretti da/a, ecc…). Più che una funzionalità di analisi è da ritenersi una facility che aiuta a concentrarsi sul lavoro in corso ed evita errori dovuti a switch di finestre/ambienti;
  • xUnit Text, Visual Studio 2013 ha introdotto un nuovo sistema di gestione degli Unit Test che consente di selezionare il framework di testing più adatto alle proprie esigenze (tramite Adapter) ed utilizzarlo in modo nativo.

Ovviamente a queste funzionalità, utilizzabili direttamente da Visual Studio (2013), si aggiungono tutte quelle tipiche di un processo evoluto di ALM legate a VSO/TFS.

code analysis

Code Analysis

code metrics

Code Metrics

code clone analysis

Code Clone Analysis

codelens

CodeLens

Comments are closed.