Introduzione al debito tecnico
Il debito tecnico è un termine che descrive i costi futuri che verranno sostenuti se si sceglie oggi una soluzione semplice, anziché usare procedure più adatte perché richiederebbero più tempo per essere completate.
Il termine debito tecnico è stato scelto perché può essere confrontato con il debito finanziario. In genere chi si occupa di debito finanziario prende decisioni che sembrano al momento appropriate o l'unica opzione possibile, ma in questo modo, gli interessi aumentano.
Più alto è l'interesse accumulato, maggiori saranno le difficoltà e minori saranno le opzioni disponibili adottabili successivamente. Con il debito finanziario, gli interessi si accumulano presto creando un effetto palla di neve. Analogamente, il debito tecnico può accumularsi fino al punto tale che gli sviluppatori sono costretti a dedicare quasi tutto il loro tempo a classificare i problemi e ripetere il lavoro, sia esso pianificato o meno, piuttosto che aggiungere valore.
Ma come accade?
Una delle più comuni giustificazioni sono le scadenze in tempi molti stretti. Quando gli sviluppatori devono creare rapidamente un codice, spesso scelgono scelte rapide da tastiera. Ad esempio, per includere nuove funzionalità, anziché effettuare il refactoring di un metodo, il metodo viene copiato per creare una nuova versione. A questo punto viene verificato il nuovo codice ed è possibile evitare il livello di test richiesto se si modifica il metodo originale poiché è usato in altre parti del codice.
Si ottengono così due copie dello stesso codice che sarà necessario modificare in futuro, anziché una, correndo così il rischio di divergenza della logica. Le cause sono molte. Ad esempio, potrebbero mancare le competenze tecniche e la maturità tra gli sviluppatori o potrebbe mancare un chiara proprietà o direzione del prodotto.
L'organizzazione potrebbe non avere standard di codifica. È possibile che gli sviluppatori non sapessero nemmeno cosa avrebbero dovuto creare. Gli sviluppatori potrebbero non avere requisiti precisi da soddisfare e potrebbero dover affrontare modifiche dei requisiti dell'ultimo minuto.
È possibile che il refactoring necessario si stato effettuato in ritardo. Potrebbe mancare un test di qualità del codice, manuale o automatizzato. In definitiva, sta diventando sempre più difficile assicurare valore ai clienti in un intervallo di tempo e a un costo ragionevoli.
Il debito tecnico è uno dei motivi principali per cui i progetti non soddisfano le scadenze.
Nel corso del tempo, aumenta esattamente come il debito monetario. Motivi comuni di debito tecnico:
- Mancanza di stile e standard di codifica.
- Mancanza di progettazione o progettazione insufficiente di unit test case.
- Principi di progettazione/orientamento dell'oggetto ignorati o non compresi.
- Classi e librerie di codice monolitiche.
- Uso di tecnologia, architettura e approccio concepito in modo parziale, dimenticando che è necessario considerare tutti gli attributi di sistema che influiscono sulla manutenzione, sull'esperienza utente, sulla scalabilità e così via.
- Codice di progettazione eccessivo (aggiunta o creazione di codice non necessario, aggiunta di codice personalizzato quando le librerie esistenti sono sufficienti o creazione di livelli o componenti non necessari).
- Commenti e documentazione insufficienti.
- Codice autodocumentato non scritto (inclusi i nomi di classe, metodo e variabile descrittivi o che indicano la finalità).
- Scorciatoie per rispettare le scadenze.
- Presenza di codice non utilizzato.
Nota
Nel tempo, il debito tecnico deve essere restituito. In caso contrario, la capacità del team di risolvere i problemi e implementare nuove funzionalità e miglioramenti richiederà più tempo e alla fine i costi saranno proibitivi.
Si è visto che il debito tecnico aggiunge una serie di problemi durante lo sviluppo e rende molto più difficile offrire valore aggiunto al cliente.
Avere un debito tecnico in un progetto compromette la produttività, crea frustrazione tra i team di sviluppo, rende il codice difficile da comprendere e vulnerabile, aumenta il tempo necessario per apportare e convalidare le modifiche. Il lavoro non pianificato spesso diventa un intralcio al lavoro pianificato.
A lungo termine, indebolisce anche l'organizzazione. Il debito tecnico tende a cogliere di sorpresa un'organizzazione. All'inizio è piccolo poi cresce nel tempo. Ogni volta che si prende una scorciatoia o si aggira un test perché bisogna affrettarsi ad apportare le modifiche, il problema peggiora. I costi di supporto diventano sempre più alti e inevitabilmente si verifica un problema grave.
Alla fine l'organizzazione non può rispondere alle esigenze dei clienti in modo tempestivo e conveniente.
Misurazione automatizzata per il monitoraggio
Uno dei modi principali per ridurre al minimo la possibilità che il debito tecnico aumenti costantemente consiste nell'usare test e valutazione automatizzati.
Nelle demo seguenti si esaminerà uno degli strumenti comuni usati per valutare il debito: SonarCloud. La versione locale originale era SonarQube.
Esistono altri strumenti, alcuni dei quali verranno illustrati.
Più avanti, nell'esercitazione pratica successiva verrà descritto come configurare Azure Pipelines per usare SonarCloud, comprendere i risultati dell'analisi e infine come configurare i profili di qualità per controllare i set di regole usati da SonarCloud durante l'analisi dei progetti.
Per altre informazioni, vedere SonarCloud.
Per riepilogare:
Azure DevOps può essere integrato con un'ampia gamma di strumenti esistenti usati per controllare la qualità del codice durante le compilazioni.
Quali strumenti per verificare la qualità del codice vengono attualmente usati (se ne viene usato qualcuno)?
Cosa viene apprezzato o meno di questi strumenti?