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

17

Considerando come il software viene sviluppato durante un ciclo di rilascio (implementazione, test, correzione di bug, rilascio) stavo pensando che si dovrebbe essere in grado di vedere alcuni pattern nelle righe di codice che vengono cambiati nella base di codice; ad es. verso la fine di un progetto, se il codice diventa più stabile, si dovrebbe vedere che vengono modificate meno righe di codice per unità di tempo.

Ad esempio, si potrebbe vedere che durante i primi sei mesi del progetto, la media era di 200 righe di codice al giorno mentre durante l'ultimo mese era di 50 righe di codice al giorno e durante l'ultima settimana (poco prima del DVD del prodotto sono stati spediti), nessuna riga di codice è stata modificata (blocco del codice). Questo è solo un esempio e potrebbero emergere diversi modelli in base al processo di sviluppo adottato da un determinato team.

Ad ogni modo, ci sono delle metriche del codice (qualche letteratura su di esse?) Che usano il numero di righe di codice modificate per unità di tempo per misurare la stabilità di una base di codice? Sono utili per capire se un progetto sta arrivando da qualche parte o se è ancora lungi dall'essere pronto per essere pubblicato? Esistono strumenti in grado di estrarre queste informazioni da un sistema di controllo versione e produrre statistiche?

code-metrics

— Giorgio
fonte

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

4

"In secondo luogo, essendo il meccanismo astratto, la sua produzione è inclusa nel suo design. A questo proposito un programma è come una poesia: non puoi scrivere una poesia senza scriverla. Eppure la gente parla di programmazione come se fosse un processo di produzione e misura" produttività del programmatore "in termini di" numero di righe di codice prodotte ". In tal modo prenotano quel numero dalla parte sbagliata del libro mastro: dovremmo sempre fare riferimento al" numero di righe di codice spese "." - I frutti dell'incomprensione , Edsger W. Dijkstra.

— yannis,

3

@Yannis Rizos: non sto affatto suggerendo di misurare la produttività o la complessità del codice da LOC perché so che questa non è una buona misura. D'altra parte, se 300 righe di codice fossero cambiate due giorni prima della spedizione, come manager avrei in mente una grande lampada "ALLARME ROSSO" (a meno che non fosse stata pianificata ed è il risultato di una valutazione molto attenta dei rischi ). In generale, suppongo che il codice che è stato usato (e testato) senza essere modificato per lungo tempo sia "più stabile" del codice in cui 100 linee vengono cambiate ogni giorno.

— Giorgio,

2

@Giorgio Argh, sono stato interrotto (a metà giornata lavorativa qui) mentre stavo postando un altro commento (ho raggiunto il limite di caratteri nel primo). Non intendevo implicare che stavi parlando della produttività, mi è appena venuta in mente la citazione di Dijkstra e ho pensato che sarebbe stato interessante. In ogni caso, le metriche di churn del codice si avvicinano molto a ciò che stai cercando e ci sono tonnellate di letteratura su di esse. Per quanto riguarda gli strumenti, Atlassian's FishEye è spettacolare.

— yannis,

@Yannis Rizos: è davvero una lettura molto interessante. Per quanto riguarda FishEye, lo usiamo sul nostro posto di lavoro (per le recensioni), quindi esaminerò immediatamente il manuale e vedremo che tipo di statistiche possiamo produrre.

— Giorgio,

17

Una misura descritta da Michael Feather è " The Active Set of Classes ".

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

Una classe è chiusa alla data in cui non vi sono ulteriori modifiche da quella data ad oggi.

Usa queste misure per creare grafici come questo: Tabella delle classi attive

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

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

— Dave Hillier
fonte

4

Finché esiste una mappatura relativamente coerente delle funzionalità alle classi, o per quella materia, il file system è possibile agganciare qualcosa come gource nel sistema di controllo della versione e avere rapidamente un'idea di dove si concentra la maggior parte dello sviluppo (e quindi quali parti del codice sono le 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 sta lavorando a causa delle interdipendenze. Detto questo, forse quello di per sé (il clustering mentre si lavora su una funzione) è una buona indicazione della qualità della base di codice.

Presuppone inoltre che la tua azienda e il team di sviluppo nel loro insieme abbiano un modo per separare le funzionalità nello sviluppo (che si tratti di rami nel controllo della versione, una funzionalità alla volta, qualunque cosa). Se, ad esempio, stai lavorando su 3 funzionalità principali sullo stesso ramo, allora questo metodo produce risultati insignificanti, perché hai un problema più grande della stabilità del codice nelle tue mani.

Sfortunatamente, non ho letteratura per dimostrare il mio punto. Si basa esclusivamente sulla mia esperienza nell'uso di gource su basi di codice valide (e non così buone).

Se stai usando git o svn e la tua versione di gource è> = 0.39, è semplice come eseguire gource nella cartella del progetto.

— Carl
fonte

gource sembra anche essere un ottimo strumento! (+1)

— Giorgio,

1

Mi sono imbattuto in questa risposta, quindi ho trascorso le sei ore successive a giocare con Gource. Non sono sicuro che ciò meriti un +1 o un -1, ma accidenti, questo è uno strumento interessante.

— RonU,

@RonU: è possibile utilizzare gource per visualizzare lo stato del repository in un intervallo di tempo personalizzato. Il punto è che visualizza l'attività sulla base di codice nel tempo. La facilità di interpretazione delle informazioni dipende da molti fattori, come ho spiegato nella mia risposta sopra. Sì, è uno strumento fantastico se vuoi una "visione d'insieme", quindi penso che meriti un +1;)

— Carl,

Sì, quando ho detto "sei ore", non intendevo dire che ho eseguito una sim Gource per quel tempo ... solo che ho giocato con molte opzioni, l'ho convogliato su ffmpeg, forse ho aggiunto una colonna sonora epica, ecc. era piuttosto la tana del coniglio. :)

— RonU,

Fammi indovinare. La colonna sonora era Harlem Shuffle in loop;)

— Carl

0

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

Inizialmente, la distribuzione nel tempo delle linee modificate dipende fortemente dal modello di gestione del software del progetto. Ci sono grandi differenze nei diversi modelli di gestione.

In secondo luogo, l'incidente in questa ipotesi non è chiaro: è il conteggio 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 farlo dopo il pubblicazione?

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

— johnfound
fonte

"Dipende dall'abilità dello sviluppatore e dalla qualità del design.": Ma hai bisogno di almeno un po 'di tempo per testare le modifiche in modo da avere abbastanza fiducia da non aver introdotto alcun bug. Anche gli sviluppatori più abili possono fare errori di battitura, ad esempio se sono sotto pressione, hanno fatto troppi straordinari o hanno dormito troppo poco. Inoltre, se si applica il principio di apertura / chiusura, dopo un po 'il numero di modifiche (correzioni di bug) dovrebbe diminuire. In ogni caso, ho esplicitamente dichiarato nella mia domanda che il risultato di tale misurazione potrebbe cambiare in base al processo di sviluppo.

— Giorgio,

A proposito, il codice può essere instabile non perché gli sviluppatori sono cattivi, ma perché i requisiti non sono chiari e il progetto è ancora in fase di prototipazione.

— Giorgio,

@Giorgio: certo che hai ragione. Ma questo è esattamente ciò che ho scritto: il conteggio delle righe modificate dipende fortemente da troppi fattori. Alcuni riguardavano la stabilità del codice, altri no. È come provare a calcolare quante persone fanno sesso, misurando l'energia elettrica, supponendo - meno energia - meno luci - più sesso. Anche se è dimostrato che il tasso di natalità sta aumentando dopo grandi black out. ;)

— johnfound,

-1

Robustezza è un termine relativo alla corretta funzione di un set di istruzioni, non alla quantità, verbosità, terseness, correttezza grammaticale del testo utilizzato per esprimere tali istruzioni.

In effetti la sintassi è importante e deve essere corretta, ma qualsiasi cosa oltre a ciò, in quanto riguarda la funzione desiderata delle istruzioni guardando le "metriche" delle istruzioni è simile a tramare il tuo futuro leggendo lo schema delle foglie di tè in fondo a tu tazza di tè.

La robustezza viene misurata mediante test. Test unitari, test del fumo, test di regressione automatizzati; test, test, test!

La mia risposta alla tua domanda è che stai usando l'approccio sbagliato nel cercare una risposta a una di solidità. È un'aringa rossa che le linee di codice significano qualcosa di più del codice che occupa le linee. Puoi solo sapere se il codice fa quello che vuoi che faccia se provi che sta facendo quello che ti serve.

Rivedere nuovamente i corretti cablaggi di prova ed evitare il misticismo della metrica del codice.

Auguri.

— Sassafras_wot
fonte

3

Ho dichiarato esplicitamente che non stavo suggerendo LoC come misura della complessità del codice. Stavo suggerendo le modifiche al codice come misura della stabilità del codice: un pezzo di codice ha requisiti funzionali stabili e un'implementazione stabile e testata che soddisfa tali requisiti?

— Giorgio,

Non voglio discutere con te, ma ti guido rispettosamente dalla follia della mancanza di significato della metrica del codice. Rileggo la tua domanda e tutti i tuoi esempi indicano il desiderio di inferire una relazione tra le righe di codice che vengono modificate e la loro robustezza risultante. Capisco che più parole digiti, maggiore è la probabilità che tu faccia un refuso. Ma sono così contrario al suo principio in ciò che chiedi che devo venire fortemente a favore di te abbandonando la tua ricerca in questo modo. Buone pratiche di prova = buona probabilità di robustezza.

— Sassafras_wot

"Buone pratiche di prova = buona probabilità di robustezza.": Sono totalmente d'accordo. Ecco perché sto suggerendo che un pezzo di codice che è stato modificato di recente deve essere testato di nuovo prima di poter essere certi che sia corretto.

— Giorgio,

Esistono diverse definizioni di stabilità e una di queste è ciò per cui stai discutendo. È un'interpretazione semantica diversa da quella che ho fatto. Ho preso la scuderia nel senso che è "non soggetto a cambiamenti estremi" piuttosto che "resistente al cambiamento"

— Dave Hillier,