Metriche del codice sorgente per misurare la stabilità del codice?

Una misura che Michael Feather ha descritto è, " Il set attivo di classi ".

Misura il numero di classi aggiunte a quelle "chiuse". Descrive la chiusura della classe come:

A class is closed on the date at which no further modifications happen to it from that date to the present.

Usa queste misure per creare grafici come questo:

Più piccolo è il divario tra le due linee, meglio è.

Potresti essere in grado di applicare una misura simile al tuo codice base. È probabile che il numero di classi sia correlato al numero di righe di codice. Potrebbe anche essere possibile estenderlo per incorporare una riga di codice per misura di classe, che potrebbe cambiare la forma del grafico se si hanno alcune grandi classi monolitiche.

Finché esiste una mappatura relativamente coerente delle funzionalità per le classi, o per quel che riguarda il file system, è possibile collegare qualcosa come gource nel tuo sistema di controllo delle versioni e molto rapidamente hai un senso su dove si concentra la maggior parte dello sviluppo (e quindi quali parti del codice sono più instabili).

Questo presuppone che tu abbia una base di codice relativamente ordinata. Se la base di codice è una palla di fango, vedrai essenzialmente ogni piccola parte su cui si lavora a causa delle interdipendenze. Detto questo, forse questo di per sé (il clustering mentre si lavora su una funzionalità) è una buona indicazione della qualità della base di codice.

Presuppone inoltre che la tua attività e il team di sviluppo nel suo complesso abbiano un qualche modo per separare le funzionalità in fase di sviluppo (sia che si ramifichi nel controllo della versione, una funzione alla volta, qualsiasi altra cosa). Se, ad esempio, stai lavorando su 3 funzioni principali sullo stesso ramo, questo metodo produce risultati privi di significato, perché hai un problema più grande della stabilità del codice sulle tue mani.

Sfortunatamente, non ho letteratura per dimostrare il mio punto. È basato esclusivamente sulla mia esperienza nell'uso di gource su basi di codice buone (e non tanto buone).

Se stai usando git o svn e la tua versione di geg è > = 0,39, è semplice come gource in esecuzione nella cartella del progetto.

L'uso della frequenza delle linee modificate come indicatore per la stabilità del codice è quantomeno discutibile.

In un primo momento, la distribuzione nel tempo delle linee modificate dipende in gran parte dal modello di gestione del software del progetto. Esistono grandi differenze nei diversi modelli di gestione.

In secondo luogo, l'incidente in questa ipotesi non è chiaro - è il numero inferiore di linee modificate causato dalla stabilità del software, o semplicemente perché la scadenza scade e gli sviluppatori hanno deciso di non apportare alcune modifiche ora, ma di fare dopo l'uscita?

Al terzo punto, la maggior parte delle linee viene modificata quando vengono introdotte nuove funzionalità. Ma la nuova funzionalità non rende il codice non stabile. Dipende dalle capacità dello sviluppatore e dalla qualità del design. D'altra parte, potrebbero essere risolti bug anche gravi con poche righe modificate - in questo caso, la stabilità del software è aumentata in modo significativo, ma il conteggio delle righe modificato non è troppo grande.

La robustezza è un termine relativo alla funzione corretta di un set di istruzioni, non la quantità, la verbosità, la chiarezza, la correttezza grammaticale del testo usato per esprimere quelle istruzioni.

In effetti la sintassi è importante e deve essere corretta, ma qualsiasi cosa oltre, in quanto riguarda la funzione desiderata delle istruzioni, guardando le "metriche" delle istruzioni è simile a tracciare il tuo futuro leggendo il modello delle foglie di tè a il fondo della tua tazza di tè.

La robustezza è misurata attraverso test. Test unitari, test fumo, test di regressione automatizzati; test, test, test!

La mia risposta alla tua domanda è che stai usando l'approccio sbagliato nella ricerca di una risposta a uno di robustezza. È una falsa pista che le linee di codice significano qualcosa di più delle code che occupano il codice. Puoi solo sapere se il codice fa quello che vuoi che faccia, se verifichi che sta facendo ciò che ti serve.

Rivedi i corretti cablaggi di test ed evita il mystisism della metrica del codice.

I migliori auguri.