Quali sono le metriche utili da acquisire per il codice sorgente?
In che modo le metriche, come ad esempio (Eseguibile?) Linee di codice o Complessità ciclomatica aiutano con la garanzia della qualità o in che modo sono utili in generale per il processo di sviluppo del software ?
"Misurare la produttività del software per linee di codice è come misurare il progresso su un aeroplano di quanto pesa." - Bill Gates
Dai un'occhiata ai post di Jeff sull'argomento:
Una visita dalla cameriera metrica
Ingegneria del software: Dead?
C'è un vecchio, ma buono, post di Joel, strettamente correlato alle metriche del software, e consiglio vivamente di leggerlo: Il metodo di gestione di Econ 101
Il punto chiave, per me, è questo, citando Jeff: "L'uso responsabile delle metriche è importante tanto quanto raccoglierle in primo luogo."
Ciò che mi confonde delle metriche del codice è che non viene fatto di più. La maggior parte delle aziende riferisce sull'efficienza dei propri dipendenti, fornitori e sistemi, ma nessuno sembra voler riferire sul codice. Sono assolutamente d'accordo con le risposte che affermano che più linee di codice sono una responsabilità, ma ciò che fa il tuo codice è più importante.
Linee di codice: Come ho detto, questa è una misura vitale e dovrebbe essere presa più seriamente, ma a ogni livello. Funzioni, classi, file e interfacce possono indicare un codice "fai tutto" che è difficile da mantenere e costoso a lungo termine. È infinitamente difficile confrontare le linee totali del codice rispetto a ciò che fa un sistema. Potrebbe essere qualcosa che fa molte cose e in tal caso ci saranno molte righe di codice!
Complessità: Questa misura è buona cosa su basi di codice su cui non hai lavorato e può darti una buona indicazione di dove si trovano le aree problematiche. Come aneddoto utile ho misurato la complessità su una delle mie basi di codice, e l'area di maggiore complessità è stata quella che trascorrevo più tempo quando avevo bisogno di cambiarla. Lavorare per ridurre la complessità ha comportato una massiccia riduzione dei tempi di manutenzione. Se la direzione avesse queste misure a portata di mano, potrebbe pianificare il refactoring delle iterazioni o la riprogettazione di specifiche aree di un sistema.
Duplicazione codice: Questa è una misura molto importante per quanto mi riguarda. La duplicazione del codice è un segnale molto brutto e potrebbe indicare problemi profondi nei bassi livelli del design di un sistema o sviluppatori che copiano copia, causando enormi problemi a lungo termine e sistemi che non sono mantenibili.
Grafici di dipendenza Trovare dipendenze cattive e dipendenze circolari sono una misura importante nel codice. Questo indica quasi sempre un design di alto livello errato che deve essere rivisto. A volte una dipendenza può risucchiare un sacco di altre non necessarie, perché qualcuno sta usando addNumber all'interno di una libreria di posta elettronica per fare i propri calcoli finanziari. Tutti sono scioccati quando la libreria e-mail viene cambiata e le interruzioni finanziarie. Se tutto dipende da una cosa, può anche puntare a fare - tutte le librerie difficili da mantenere e progettate male.
Una buona misurazione ti dirà sempre che ogni funzione di un sistema ha un ingombro ridotto. Meno dipendenze, meno complessità, meno duplicazioni. Ciò indica un accoppiamento lento e un'elevata coesione.
Questa "metrica del codice sorgente" non cagherà MAI morire?
Le righe di codice di origine raw (SLOC) sono la metrica più vecchia, più semplice e più semplice che ci sia.
Halstead ha inizialmente proposto un intero gruppo di metriche. Molte persone si sono divertite molto a scrivere programmi di misura fino a quando un po 'di spoiler ha fatto l'ovvio studio, e hanno dimostrato che ogni singola metrica di Halstead era strongmente correlata direttamente con SLOC.
A quel punto, le metriche di Halstead sono state abbandonate, perché lo SLOC è sempre più facile da misurare.
Le metriche del codice sorgente per l'assicurazione della qualità mirano a due obiettivi:
Entrambi portano a scrivere codice il più semplice possibile. Questo significa:
In base alle mie conoscenze, il numero di bug rilevati è direttamente correlato a righe di codice (probabilmente varianza), linguaggio modulo, programmatore e dominio.
Non conosco nessuna metrica semplice e pratica ben correlata con bug.
Una cosa che mi piacerebbe fare è iniziare a gestire i numeri per i diversi progetti su cui sto lavorando - Copertura di test :: kLOC, quindi discutere di "qualità percepita" per vedere se esiste una correlazione.
Le metriche sono utili solo se sai cosa fare con le risposte che ottieni. In sostanza, una metrica del software è come un termometro. Il fatto di misurare qualcosa a 98.6 ° F non significa nulla finché non si sa quale sia la temperatura normale . La temperatura di cui sopra è buona per la temperatura corporea, ma davvero negativa per il gelato.
Le metriche comuni che possono essere utili sono:
Le prime due tendenze delle misure. Stai trovando bug più velocemente di quanto tu possa risolverli? Due possibili esiti: forse abbiamo bisogno di più risorse per correggere i bug, forse dobbiamo smettere di implementare nuove funzionalità fino a quando non ci mettiamo in pari. I secondi due forniscono un'immagine di quanto sei vicino a essere fatto. I team agili chiamano un grafico "burn down".
La complessità ciclomatica è una metrica interessante. Al suo concetto di base è il numero di percorsi di esecuzione unici in una funzione / metodo. In un ambiente pesante con test delle unità questo corrisponde al numero di test necessari per verificare ogni percorso di esecuzione. Tuttavia, solo perché hai un metodo che ha una complessità ciclopica di 96 non significa che sia necessariamente un codice bacato - o che devi scrivere 96 test per fornire una ragionevole sicurezza. Non è raro che il codice generato (tramite i generatori WPF o parser) generi qualcosa di così complesso. Può fornire un'idea approssimativa del livello di sforzo necessario per eseguire il debug di un metodo.
Bottom Line
Ogni misura che si prende deve avere la seguente definizione o è inutile:
Le metriche che prendi possono variare notevolmente da un progetto all'altro. Potresti avere alcune metriche che utilizzi per i progetti, ma la definizione di "normale" sarà diversa. Ad esempio, se un progetto scopre una media di 5 bug / settimana e il nuovo progetto scopre 10 bug / settimana, ciò non significa necessariamente che qualcosa non va. Potrebbe essere solo il team di test più meticoloso questa volta. Inoltre, la definizione di "normale" può cambiare nel corso della vita del progetto.
La metrica è solo un termometro, quello che fai con esso dipende da te.
Source il codice è una responsabilità, non una risorsa. Con questo in mente, le linee di misurazione del codice sono analoghe al monitoraggio dei dollari spesi durante la costruzione di una casa. Deve essere fatto se si vuole rimanere sotto il budget, ma non penseresti necessariamente che spendere $ 1000 al giorno sia meglio che spendere $ 50 al giorno; vorresti sapere quanta parte della casa è stata costruita per quei soldi. È lo stesso con le linee di codice in un progetto software.
In breve, non ci sono metriche utili per il codice sorgente perché misurare il codice sorgente da solo non è utile.
Poiché il codice sorgente è semplicemente una combinazione di sequenza, selezione e ripetizione. Se dovessi descrivere il software più ottimale che potremmo mai ragionevolmente aspettarci di produrre sarebbe il seguente. Software con copertura del codice di prova quasi del 100% utilizzando la quantità minima di righe di codice necessarie per eseguire il lavoro e tuttavia abbastanza flessibile da resistere alle modifiche.
Un aneddoto per mostrare perché i conteggi di KLOC sono inutili (e persino dannosi) per valutare le prestazioni.
Anni fa ho lavorato a un grande progetto (più di 70 persone nella nostra azienda, altre 30+ presso i nostri clienti) che utilizzava KLOC come l'unica misura delle prestazioni di team e individui.
Per il nostro sforzo Y2K (ti dice quanto tempo fa era :)) abbiamo fatto una grande pulizia della sezione del codice di cui il mio team era responsabile. Abbiamo finito con la pubblicazione di circa 30.000 righe di codice, non male 3 mesi di lavoro per 5 persone. Abbiamo anche finito di demolire altre 70.000 righe di codice, un ottimo lavoro per 3 mesi di lavoro, specialmente combinato con il nuovo codice.
Risultato finale per il trimestre: -40.000 righe di codice. Durante la revisione delle prestazioni successiva al trimestre abbiamo ricevuto un rimprovero ufficiale da parte dell'azienda per non aver soddisfatto i nostri requisiti di produttività di 20.000 righe di codice prodotte per trimestre (dopo tutto, gli strumenti avevano mostrato che avevamo prodotto -40.000 righe di codice), che avrebbe comportato che tutti noi venissero elencati come underperforming e bypassati per promozioni, formazione, aumento di retribuzione, ecc. ecc., se il responsabile di progetto e il team di controllo della qualità non fossero intervenuti e avessero rimproverato il rimprovero e sostituito da un encomio.
Alcuni mesi più tardi (tali cose richiedono tempo) ci è stato detto che la società stava rivedendo i loro standard di produttività e aveva assunto un team di esperti per creare un nuovo sistema basato sull'analisi dei punti di funzione.
Sono sorpreso che nessuno abbia menzionato la copertura delle dichiarazioni / decisioni delle unità (percentuale di codice esercitata dai test unitari) ancora.
La copertura del codice è utile perché sai quale percentuale dell'applicazione non fallisce in modo catastrofico; con il resto della sua utilità dipende dalla qualità dei test unitari.
Più piccolo è il commit, meglio è, di solito. Questo riguarda gli strumenti SCM, non il codice per sé, ma è una metrica molto misurabile. Più piccolo è il commit, più facile è vedere ogni cambiamento come un'unità atomica; più facile è ripristinare le modifiche specifiche e il punto di svolta quando le cose si rompono.
Finché nessun commit interrompe la build ...
Queste non sono molto utili metriche absolute in termini di progresso, ma possono essere usate per dare un'idea generale dello stato del codice.
In particolare, la complessità ciclomatica mi è sembrata utile in termini di visualizzazione della modularizzazione di una data base di codice. In genere si desidera una complessità bassa in quanto ciò significa che il numero di sorgenti per modulo è basso e ci sono molti moduli.
Lavoro spesso su un gigantesco pacchetto C ++ e quando cerco codice problematico che valuti la refactoring della complessità ciclomatica o orribili FanIn / FanOut sono solitamente bandiere rosse abbastanza buone da cercare. I problemi di risoluzione di solito porteranno a miglioramenti nell'intero codebase.
Ovviamente questi numeri possono servire solo come un suggerimento su ciò che varrebbe la pena guardare. Rendere questa una dura soglia dopo la quale fallire una build o rifiutare un commit sarebbe ridicolo.
Ci sono molte situazioni nel mio lavoro in cui utilizzo le metriche del codice:
Durante la scrittura del codice
L'uso più grande e forse più importante nel mio lavoro quotidiano è in Checkstyle , uno strumento per sviluppatori java che controlla continuamente le metriche ( tra le altre cose) del mio codice rispetto a un insieme di regole che abbiamo definito e contrassegna luoghi in cui il mio codice non è conforme a tali regole. Mentre sviluppo il codice, mi dice in tempo reale se i miei metodi diventano troppo lunghi, complessi o accoppiati, permettendomi di fare un passo indietro e pensare di rifarlo a qualcosa di meglio.
Gli sviluppatori sono completamente liberi di violare tutte le regole poiché non si applicheranno mai a tutte le situazioni. Le "regole" sono lì per stimolare il pensiero e dire "Ehi, è questo il modo migliore per farlo?"
Durante recensioni su QA / Codice
La prima cosa che faccio generalmente quando eseguo una revisione del codice è controllare la copertura del codice del codice che sto esaminando insieme a uno strumento di copertura del codice che evidenzia quali linee di codice sono state coperte. Questo mi dà un'idea generale di quanto sia accurato il codice di test. Non mi interessa davvero se la copertura è del 20% o 100% finché il codice importante è ben testato. Quindi la percentuale coperta è alquanto insignificante, ma lo 0% sicuramente si distingue come un pollice dolente come qualcosa che voglio guardare attentamente.
Controllo anche quali metriche concordate dal team sono state "infrante", se esistono, per vedere se sono d'accordo con lo sviluppatore sul fatto che fosse OK o se posso suggerire modi per migliorarlo. Avere questi parametri di sviluppo concordati nel nostro team per scrivere un nuovo codice ha fatto grandi progressi nel migliorare il nostro codice. Scriviamo molto meno metodi monolitici e siamo molto meglio al principio di responsabilità singola adesso.
Miglioramenti delle tendenze al codice precedente Abbiamo un sacco di codice legacy che vorremmo migliorare. Le metriche in qualsiasi momento sono abbastanza inutili, ma ciò che è importante per noi è che la copertura del codice temporale aumenti e che cose come la complessità e l'accoppiamento scendano. Pertanto, le nostre metriche sono collegate al nostro server di Continuous Integration che ci consente di guardare nel tempo per assicurarci di essere sulla strada giusta.
Affrontare una nuova base di codice Circa l'unica volta che uso linee di metrica del codice sorgente è quando guardo un codice base che non conosco. Mi consente di misurare rapidamente le dimensioni approssimative del progetto rispetto ad altre con cui ho lavorato. Usando altre metriche posso avere un'idea più approssimativa della qualità del progetto.
Le cose chiave sono usare le metriche come punti di partenza per trend, discussioni o strade da percorrere e non per gestirle religiosamente su cifre esatte. Ma credo fermamente che possano aiutarti a migliorare il codice che hai ragione quando usato correttamente.
D: Quali sono le metriche utili da acquisire per il codice sorgente?
Per le aziende:
A: Numero di ore uomo
Per supervisore del coder:
A: non importa. Facciamo tutto oggi
Per l'autostima del coder:
A: Numero di SLOC (Linee di codice sorgente)
Per la madre del coder:
A: mangia più di questi morbidi panini francesi e bevi il tè
continua nei commenti sotto ...
Ricorda: tutto il codice può essere ridotto di almeno 1 istruzione. Tutto il codice ha almeno 1 bug. Pertanto, tutto il codice può essere ridotto a una singola istruzione che non funziona. Spero che ti aiuti!
Leggi altre domande sui tag code-quality metrics