Qualcuno sa se esiste un qualche tipo di strumento per mettere un numero sul debito tecnico di una base di codice, come una sorta di metrica del codice? In caso contrario, qualcuno è a conoscenza di un algoritmo o di una serie di euristiche per questo?

Se nessuna di queste cose esiste finora, sarei interessato a idee su come iniziare con una cosa del genere. Cioè, come posso quantificare il debito tecnico sostenuto da un metodo, una classe, uno spazio dei nomi, un assembly, ecc.

Sono molto interessato all'analisi e alla valutazione di una base di codice C #, ma non esitate a cercare anche altre lingue, in particolare se i concetti sono trascendenti.

Il debito tecnico è solo un'idea astratta che, da qualche parte lungo le linee di progettazione, costruzione, test e manutenzione di un sistema, sono state prese alcune decisioni in modo tale che il prodotto è diventato più difficile da testare e mantenere. Avere più debito tecnico significa che sarà più difficile continuare a sviluppare un sistema: o è necessario far fronte al debito tecnico e allocare sempre più tempo per quelli che altrimenti sarebbero compiti semplici, oppure è necessario investire risorse (tempo e denaro) per ridurre il debito tecnico attraverso il refactoring del codice, il miglioramento dei test e così via.

Esistono diverse metriche che potrebbero darti qualche indicazione sulla qualità del codice:

• Copertura del codice. Esistono vari strumenti che indicano quale percentuale di funzioni, istruzioni e righe sono coperte dai test unitari. È inoltre possibile mappare i 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 coesione . Il codice che presenta basso accoppiamento e elevata coesione è in genere più facile da leggere, comprendere e testare. Esistono strumenti di analisi del codice che possono segnalare la quantità di accoppiamento e coesione in un determinato sistema.
• La complessità ciclomatica è il numero di percorsi unici attraverso un'applicazione. In genere viene conteggiato a livello di metodo / funzione. La complessità ciclomatica è correlata alla comprensibilità e testabilità di un modulo. Non solo valori di complessità ciclomatica più elevati 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 volume, difficoltà e sforzo. Spesso, questi possono indicare quanto sarà difficile per qualcuno raccogliere il codice e comprenderlo, spesso in casi come una revisione del codice o un nuovo sviluppatore alla base di 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ù righe 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, gli strumenti di analisi statica saranno in grado di avvisarti di potenziali problemi. Ovviamente, solo perché uno strumento indica un problema non significa che ci sia un problema: occorre un giudizio umano per determinare se qualcosa potrebbe essere problematico lungo la strada. Queste metriche ti avvisano che potrebbe essere il momento di esaminare un sistema o un modulo più da vicino.

Tuttavia, questi attributi si concentrano sul codice. Non indicano prontamente alcun debito tecnico nell'architettura o nella progettazione del sistema che potrebbe essere correlato a vari attributi di qualità.

Il sonar ha un'euristica del debito tecnico e diverse altre funzioni utili a un progetto software.

Supporta anche una vasta gamma di lingue.

SonarQube (precedentemente Sonar ) è una piattaforma open source per l'ispezione continua della qualità del codice ...

• Supporta oltre 25 lingue: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL, ecc.
• SonarQube è utilizzato anche in Android Deveopment.
• Offre report su codice duplicato, standard di codifica, unit test, copertura del codice, codice complesso, potenziali bug, commenti, design e architettura.
• Macchina del tempo e viste differenziali.
• Analisi completamente automatizzate: si integra con Maven, Ant, Gradle e strumenti di integrazione continua (Atlassian Bamboo, Jenkins, Hudson, ecc.).
• Si integra con l'ambiente di sviluppo Eclipse
• Si integra con strumenti esterni: JIRA, Mantis, LDAP, Fortify, ecc.
• Espandibile con l'uso di plugin.
• Implementa la metodologia SQALE per calcolare il debito tecnico ...

Odio usare un'analogia dalla finanza, ma sembra davvero appropriato. Quando stai valutando 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 un valore estrinseco (valore da ciò che si potrebbe fare al codice) e tali quantità sarebbero additive. Il valore intrinseco può essere suddiviso in crediti e debiti (buoni contro cattivi) usando qualunque metodologia stai usando per assegnare un punteggio al codice (+5 per commenti / leggibilità, -10 per copertura del codice, ecc.)

Sicuramente non conosco alcuno strumento che possa quantificarlo oggi e penso che avresti una discussione completamente nuova tra le mani se discuti i meriti delle diverse strategie di "valutazione del debito" ma sono d'accordo con Matthew - il debito è il costo cumulativo per ottenere il codice il più bene possibile, usando qualunque metodo tu usi per costare le ore di lavoro necessarie per arrivarci.

Qualcos'altro da considerare è che esiste sicuramente una misura del rapporto costo-efficacia in base al quale, man mano che ci si avvicina alla "perfezione", il valore di un'ora trascorsa sulla base di codice sta probabilmente diminuendo in modo esponenziale, quindi c'è probabilmente un ulteriore problema di ottimizzazione a massimizzare l'utilità del lavoro svolto.

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 "all'esterno".}

La metrica che ha funzionato per me nel comunicare il debito tecnico agli "estranei" è stata la quantità di test e sforzi di correzione dei bug (in particolare per correggere i bug di regressione ) necessari per la consegna corretta.

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

• è molto più facile dichiarare 3 settimane di spesa totale per l'implementazione della funzione A che
   
  ho speso 14 ore per la bozza dell'implementazione della funzione A, quindi 29 ore per testare il fumo, quindi 11 ore per implementare le correzioni per le regressioni che ho scoperto, quindi 18 ore per testare il QA già funzionalità di implementazione. Successivamente, i ragazzi del QA hanno trascorso 17 ore a testare la versione iniziale del candidato. Successivamente ho trascorso 13 ore ad analizzare i bug inviati dal QA per la versione iniziale del candidato e 3 ore a implementare le correzioni. Dopodiché, ho trascorso 11 ore a testare il fumo sulle modifiche apportate alla versione iniziale del candidato. Dopo di che...

In ogni caso, nella mia esperienza sono stati abbastanza facili comunicare i dati relativi ai test e alle attività di correzione dei bug.

Per la versione recente, abbiamo impiegato circa il 90% del tempo a testare e correggere bug di regressione. Per la prossima versione, suggerire di dedicare un po 'di sforzo per ottenere questo valore fino al 60-70%.

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

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

• Supponiamo che ci siano due componenti / applicazioni simili gestiti dallo stesso sviluppatore (i), prima rilasciando al "tasso di spreco" circa il 50% e in secondo luogo a 80-90, questo è un caso abbastanza forte a favore del secondo soggetto di debito tecnico.

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

Con i tester, ottieni qualcuno per il backup della tua comprensione dei problemi di progettazione. Quando ci sono solo sviluppatori che si lamentano della qualità del codice , questo suona spesso come WTF soggettivi da dietro la porta chiusa .
 
Ma quando questo viene ripetuto da un responsabile della qualità che dice che qualcosa del genere component Aaveva 100 bug di regressione per 10 nuove funzionalità, al contrario del component Bquale c'erano 10 bug di regressione per 20 nuove funzionalità , la comunicazione si trasforma improvvisamente in un altro gioco.

Penso che la domanda sia: quanto costerebbe "riacquistare" il tuo debito tecnico - vale a dire, quanto lavoro è necessario per risolverlo? Bene, sta alla squadra capirlo.

Durante la pianificazione dello sprint, chiedo al team di stimare la complessità della correzione degli elementi di debito tecnici nello stesso modo in cui stimerebbero la complessità di una user story. A quel punto, è un gioco di negoziazione tra la squadra e il proprietario del prodotto per determinare quale debito tecnico ha una priorità abbastanza alta da essere fatto nello sprint corrente (sostituendo le storie degli utenti reali) e cosa può aspettare.

Se non stai facendo la mischia, mi atterrei alla mia premessa: il debito tecnico dovrebbe essere misurato dal costo del rimedio.

C'è una piattaforma abbastanza potente là fuori chiamata CASTcercare debiti tecnici in grandi applicazioni. Lo abbiamo utilizzato in un progetto in cui abbiamo acquisito un grande potenziamento di un sistema legacy. Non ti dice cosa c'era nella testa delle persone che hanno scritto il codice, ma esamina il codice e trova i difetti del codice e dell'architettura, quindi quantifica il debito tecnico se lo desideri. Il vero uso nel guardare questo, tuttavia, non è la quantità di $ ma l'elenco dei problemi già presenti nel codice. Questo ti dice di una parte del debito tecnico che hai (quindi non sono d'accordo con alcune delle risposte sopra). C'è qualche debito tecnico che è puramente basato sul design ed è molto soggettivo - come la pornografia - lo conosci quando lo vedi e conosci il contesto. Direi se si tratta davvero di un debito "tecnico". C'è qualche debito tecnico che è puramente nell'esecuzione e credo che '

Ecco un webinar del MIT che descrive la ricerca sul debito tecnico nei sistemi software di grandi dimensioni: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Gli autori hanno scritto codice per analizzare un progetto ed estrarre metriche di "complessità architettonica". È stato dimostrato che queste metriche hanno una forte 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à condotta da Alan MacCormack e Carliss Baldwin presso la Harvard Business School. Vorrei guardare 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 fornirà un "indice di manutenibilità" basato su complessità ciclica, accoppiamento, LoC e profondità dell'ereditarietà. Puoi immergerti in qualsiasi punto problematico e vedere i dettagli (fino al livello di funzione). L'ho appena eseguito sul mio progetto e i punteggi più bassi che abbiamo ottenuto erano 69 sul nostro pacchetto di dati (configurazione e inizializzazione di EF) e sulla nostra suite di test. Tutto il resto era 90 o superiore. Ci sono altri strumenti che ti daranno più parametri come quelli discussi nel PPP di zio Bob

Non penserei al debito tecnico come a un dollaro in cui hai bisogno di un modello elaborato per quantificarlo. Lo considererei un favore. Se qualcuno ti fa un favore e probabilmente ti dimentichi, lo scrivi. Quando prendi una scorciatoia, scrivila. Questo ti aiuta a ricordare e più impotenti ti obbligano a riconoscerlo. Non è necessario alcuno strumento di fantasia. Notepad o Ecxel possono fare il trucco.

Lavoro per un'azienda che sta esaminando esattamente questo. Di seguito sono riportati 3 parametri attuabili che consigliamo di esaminare quando si affronta il debito tecnico. Per ulteriori informazioni su "come" e "quando" per seguirli, abbiamo messo insieme un articolo di sintesi 3 Metriche per capire e affrontare il debito tecnico .

Quali sono i tuoi pensieri? Felice di rispondere a qualsiasi domanda e affamato di sentire il tuo feedback :).

Proprietà per prevenire difetti e indebitamento tecnologico indesiderato

La proprietà è un indicatore principale della salute dell'ingegneria.

Le parti della base di codice che ricevono contributi da molte persone si accumulano nel tempo, mentre quelle che ricevono contributi da un minor numero di persone tendono ad essere in uno stato migliore. È più facile mantenere standard elevati in un gruppo ristretto che è ben informato sulla loro parte della base di codice.

Ciò fornisce un certo potere predittivo: è probabile che parti della base di codice debolmente accumulate accumulino debito nel tempo e diventino sempre più difficili da lavorare. In particolare, è probabile che il debito venga assunto involontariamente , semplicemente come un effetto collaterale di informazioni incomplete e di proprietà diluita della qualità del codice.

Questo è in qualche modo analogo alla tragedia dei beni comuni .

Coesione per migliorare l'architettura

La coesione è un indicatore finale di componenti ben definiti.

La coesione e la sua controparte, l'accoppiamento, sono state a lungo riconosciute come concetti importanti su cui concentrarsi nella progettazione del software.

Si dice che il codice abbia un'alta coesione quando la maggior parte dei suoi elementi appartiene insieme. L'alta coesione è generalmente preferibile perché associata a manutenibilità, riusabilità e robustezza. Alta coesione e accoppiamento lento tendono ad andare di pari passo.

Oltre ad essere associato a codice più riutilizzabile e mantenibile, l'elevata coesione riduce anche il numero di persone che devono essere coinvolte per modificare una determinata parte della base di codice che aumenta la produttività.

Churn per identificare le aree problematiche

Churn (attività ripetuta) aiuta a identificare e classificare le aree mature per il refactoring in un sistema in crescita.

Man mano che i sistemi crescono, diventa più difficile per gli sviluppatori comprendere la loro architettura. Se gli sviluppatori devono modificare molte parti della base di codice per fornire una nuova funzionalità, sarà difficile per loro evitare di introdurre effetti collaterali che portano a bug e saranno meno produttivi perché devono familiarizzare con più elementi e concetti.

Questo è il motivo per cui è importante lottare per una singola responsabilità per creare un sistema più stabile ed evitare conseguenze indesiderate. Mentre alcuni file sono hub architetturali e rimangono attivi quando vengono aggiunte nuove funzionalità, è una buona idea scrivere codice in modo da chiudere i file e rivedere, testare e testare rigorosamente le aree di sfocatura del QA.

Abbandona questi file attivi in ​​modo da poter decidere se devono essere suddivisi per ridurre l'area di modifica della base di codice.

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