Come posso quantificare la quantità di debito tecnico esistente in un progetto?

Il debito tecnico è solo un'idea astratta che, in qualche modo lungo la linea di progettazione, costruzione, test e manutenzione di un sistema, sono state prese alcune decisioni in modo tale che il prodotto sia diventato più difficile da testare e mantenere. Avere più debito tecnico significa che diventerà più difficile continuare a sviluppare un sistema - o è necessario far fronte al debito tecnico e allocare sempre più tempo per attività che sarebbero altrimenti semplici, oppure è necessario investire risorse (tempo e denaro) nella riduzione del debito tecnico mediante il refactoring del codice, il miglioramento dei test e così via.

Ci sono un certo numero di parametri che potrebbero darti qualche indicazione sulla qualità del codice:

• Copertura del codice. Lì sono vari strumenti che ti dicono quale percentuale delle tue funzioni, dichiarazioni e linee sono coperte dai test unitari. È inoltre possibile eseguire il mapping dei test di sistema e di accettazione ai requisiti per determinare la percentuale di requisiti coperti da un test a livello di sistema. La copertura appropriata dipende dalla natura dell'applicazione.
• Accoppiamento e la coesione . Il codice che presenta un basso accoppiamento e un'elevata coesione è in genere più facile da leggere, comprendere e testare. Esistono strumenti di analisi del codice in grado di segnalare la quantità di accoppiamento e coesione in un dato sistema.
• La complessità ciclica è il numero di percorsi unici attraverso un'applicazione. Generalmente viene contato al livello metodo / funzione. La complessità ciclomatica è legata alla comprensibilità e alla testabilità di un modulo. Non solo i maggiori valori di complessità ciclomatica indicano che qualcuno avrà più problemi a seguire il codice, ma la complessità ciclomatica indica anche il numero di casi di test richiesti per raggiungere la copertura.
• Le varie misure di complessità di Halstead forniscono informazioni sulla leggibilità del codice. Questi contano gli operatori e gli operandi per determinare il volume, la difficoltà e lo sforzo. Spesso, questi possono indicare quanto sia difficile per qualcuno prendere il codice e capirlo, spesso in istanze come una revisione del codice o un nuovo sviluppatore alla base del codice.
• Quantità di codice duplicato. Il codice duplicato può indicare il potenziale per il refactoring dei metodi. Avere un codice duplicato significa che ci sono più linee per l'introduzione di un bug e una maggiore probabilità che gli stessi difetti esistano in più punti. Se la stessa logica aziendale esiste in più punti, diventa più difficile aggiornare il sistema per tenere conto delle modifiche.

Spesso, strumenti di analisi statici ti avvisano di potenziali problemi. Certo, solo perché uno strumento indica un problema non significa che ci sia un problema - ci vuole un giudizio umano per determinare se qualcosa potrebbe essere problematico lungo la strada. Queste metriche ti danno solo degli avvertimenti che potrebbe essere il momento di guardare più da vicino un sistema o un modulo.

Tuttavia, questi attributi si concentrano sul codice. Non indicano prontamente eventuali debiti tecnici nell'architettura o nella progettazione del sistema che potrebbero riguardare vari attributi di qualità.

Sonar ha un'euristica del debito tecnico e molte altre funzionalità utili per un progetto software.

Supporta anche una vasta gamma di lingue.

SonarQube (formerly Sonar) is an open source platform for Continuous Inspection of code quality...

• Support 25+ languages: Java, C/C++, C#, PHP, Flex, Groovy, JavaScript, Python, PL/SQL, COBOL, etc.
• SonarQube is also used in Android Deveopment.
• Offers reports on duplicated code, coding standards, unit tests, code coverage, complex code, potential bugs, comments and design and architecture.
• Time machine and differential views.
• Fully automated analyses: integrates with Maven, Ant, Gradle and continuous integration tools (Atlassian Bamboo, Jenkins, Hudson, etc.).
• Integrates with the Eclipse development environment
• Integrates with external tools: JIRA, Mantis, LDAP, Fortify, etc.
• Expandable with the use of plugins.
• Implements SQALE methodology to compute technical debt...

Detesto usare un'analogia dalla finanza, ma sembra davvero appropriato. Quando si valuta qualcosa (attività di qualsiasi tipo), può avere sia valore intrinseco che estrinseco. In questo caso, il codice esistente ha un valore intrinseco che sarebbe una quantità corrispondente alla qualità relativa di detto codice e avrebbe anche valore estrinseco (valore da ciò che potrebbe essere fatto al codice) e tali quantità sarebbero additive. Il valore intrinseco può essere suddiviso in crediti e debiti (buoni o cattivi) utilizzando qualsiasi metodologia utilizzata per segnare il codice (+5 per commenti / leggibilità, -10 per copertura del codice, ecc.)

Sicuramente non conosco alcuno strumento per quantificarlo oggi e penso che avresti una discussione completamente nuova sulle tue mani se sosterrai i meriti di diverse strategie di "valutazione del debito" ma sono d'accordo con Matthew - il il debito è il costo cumulativo di ottenere il codice nel modo migliore possibile, usando qualunque metodo tu usi per ridurre le ore lavorative necessarie per arrivarci.

Qualcos'altro da considerare è che esiste certamente una misura del rapporto costo-efficacia per cui quando ci si avvicina alla "perfezione", il valore di un'ora speso per il codice base è più che probabile che diminuisce in modo esponenziale quindi c'è probabilmente un ulteriore problema di ottimizzazione per massimizzare l'utilità del lavoro svolto.

Penso che la domanda sia quanto costerebbe "riacquistare" il proprio debito tecnico - cioè, quanto lavoro è necessario per risolverlo? Bene, dipende dalla squadra per capirlo.

Durante la pianificazione dello sprint, chiedo al team di stimare la complessità della risoluzione degli elementi del debito tecnico nello stesso modo in cui stimano la complessità di una storia utente. A quel punto, è un gioco di negoziazione tra il team e il proprietario del prodotto per determinare quale debito tecnico ha una priorità sufficientemente alta da essere eseguito nello sprint corrente (rimuovendo le storie utente reali) e cosa può aspettare.

Se non stai facendo mischia, rispetterei le mie premesse: il debito tecnico dovrebbe essere misurato in base al costo del rimedio.

Tra gli sviluppatori una misura abbastanza affidabile del debito tecnico sembra essere WTF / minuto .

_{Il problema con questa "metrica" è che in genere è piuttosto difficile comunicare "fuori".}

La metrica che ha funzionato per me nella comunicazione del debito tecnico con "outsider" è stata quantità di test e sforzi di risoluzione dei bug (in particolare per il fixing bug di regressione ) necessari per il successo della consegna.

Una parola di cautela: sebbene questo approccio sia abbastanza potente, è preferibile ricontrollare con i buoni vecchi WTF / minuto prima di ricorrere ad esso. Il fatto è che è piuttosto ingombrante: per ottenere i dati, bisogna monitorare attentamente il tempo e registrarlo accuratamente per categorie appropriate.

• è molto più facile indicare 3 settimane totali spesi per l'implementazione della funzione A rispetto a
  
  Ho trascorso 14 ore sull'implementazione della bozza della funzione A, quindi su 29 ore sul fumo per testarlo, quindi su 11 ore sull'implementazione di correzioni per le regressioni che ho scoperto, quindi 18 ore per testare l'implementazione della funzionalità pronta per il QA. Successivamente, i membri del QA hanno trascorso 17 ore a testare la versione iniziale del candidato. Successivamente ho trascorso 13 ore analizzando i bug inviati dal QA per la release iniziale del candidato e 3 ore implementando le correzioni. Dopo di ciò, ho passato 11 ore a fumare testando le modifiche apportate alla versione iniziale del candidato. Dopo che ...

In ogni caso, i dati relativi ai test e alla risoluzione dei bug sono stati abbastanza facili da comunicare nella mia esperienza.

For recent release, we spent about 90% time on testing and fixing regression bugs. For next release, suggest to allocate some effort on getting this value down to 60-70%.

Un'altra parola di cautela. Dati come 90% sopra potrebbero essere interpretati non solo come un'indicazione del debito tecnico, ma anche (sorpresa a sorpresa) come indicazione di uno che non è abbastanza abile nella programmazione / tecnologia particolare. "Fai solo troppi bug nel tuo codice".

Se esiste il rischio che i dati vengano interpretati erroneamente in questo modo, è utile disporre di dati di riferimento aggiuntivi su qualcosa di meno incline al WTF da confrontare.

• Supponiamo che ci siano due componenti / applicazioni simili gestiti dallo stesso (i) sviluppatore (i primi rilasciando a "tasso di scarto" circa il 50% e il secondo a 80-90), questo rappresenta un caso piuttosto favorevole a favore di secondi essere oggetto di debito tecnico.

Se nel progetto ci sono tester dedicati, potrebbero anche contribuire a una valutazione più obiettiva dei dati. Come accennato in un'altra risposta ,

With testers, you get someone to backup your understanding of design issues. When there are only developers complaining about code quality, this often sounds like subjective WTFs from behind the closed door.
 
But when this is echoed by QA guy saying something like component A had 100 regression bugs for 10 new features, as opposed to component B which had 10 regression bugs per 20 new features, communication suddenly turns into whole another game.

Esiste una piattaforma piuttosto strong chiamata CAST per cercare il debito tecnico nelle grandi applicazioni. L'abbiamo usato su un progetto in cui abbiamo assunto un grande miglioramento per un sistema legacy. Non ti dice cosa c'era nella testa della gente che ha scritto il codice, ma esamina il codice e trova difetti di codice e di architettura, quindi quantifica il debito tecnico se lo desideri. L'uso reale in questo, però, non è l'importo in $ ma l'elenco dei problemi già nel codice. Questo ti dice di una parte del debito tecnico che hai (quindi non sono d'accordo con alcune delle risposte sopra). C'è un debito tecnico che è puramente basato sul design e che è molto soggettivo - come la pornografia - lo conosci quando lo vedi e conosci il contesto. Vorrei discutere se questo è davvero un debito "tecnico". C'è del debito tecnico che è puramente nell'implementazione e credo che valga la pena misurare e rintracciare.

Questo è un webinar del MIT che descrive la ricerca sul debito tecnico in grandi sistemi software: link

Gli autori hanno scritto il codice per analizzare un progetto ed estrarre le metriche di 'complessità architettonica'. Queste metriche hanno dimostrato di avere una strong relazione con la densità dei difetti, la produttività degli sviluppatori e il turnover del personale di sviluppo.

Il lavoro descritto nel webinar si basa sulla ricerca sulla modularità svolta da Alan MacCormack e Carliss Baldwin alla Harvard Business School. Guarderei anche i loro documenti. Il loro "costo di propagazione" potrebbe essere quello che stai cercando.

Direi che le metriche del codice standard possono essere utilizzate come una visione relativa di alto livello dell'indebitamento tecnico. VS Ultimate include un analizzatore di codice che ti darà un "Indice di manutenibilità" basato sulla complessità ciclopica, sull'accoppiamento, sullo LoC e sulla profondità dell'ereditarietà. Puoi tuffarti in qualsiasi punto problematico e vedere i dettagli (fino al livello della funzione). L'ho appena eseguito sul mio progetto e i punteggi più bassi ottenuti sono stati 69 sul nostro pacchetto di dati (configurazione e inizializzazione EF) e la nostra suite di test. Tutto il resto era 90 o sopra. Ci sono altri strumenti che ti daranno più metriche come quelle discusse in Uncle Bob's PPP

Non penserei al debito tecnico come dollari in cui hai bisogno di un modello di fantasia per quantificarlo. Lo penserei come un favore. Se qualcuno ti fa un favore e probabilmente ti dimentichi, lo scrivi. Quando prendi una scorciatoia, annotala. Questo ti aiuta a ricordare, e più impotente ti costringe a riconoscerlo. Non è necessario uno strumento di fantasia. Blocco note o Ecxel possono fare il trucco.

Se hai una buona storia tramite un bugtracker o una sorta di software agile puoi mantenerlo semplice. Tempo trascorso a completare le attività di base. Inoltre, l'affidabilità delle stime quando il progetto era giovane rispetto a ora.