it-swarm.it

Quali sono metriche utili per il codice sorgente?

Quali sono le metriche utili da acquisire per il codice sorgente?

In che modo le metriche, come ad esempio (eseguibile?) Righe di codice o Complessità ciclomatica aiutano a garantire la qualità o in che modo sono utili in generale per il processo di sviluppo del software?

33
cschol

"Misurare la produttività del software in base a righe di codice è come misurare i progressi su un aereo di quanto pesa." - Bill Gates

30
chrisaycock

Dai un'occhiata ai post di Jeff sull'argomento:

A Visit from the Metrics Maid

Ingegneria del software: morto?

C'è anche un vecchio, ma buono, post di Joel, strettamente correlato alle metriche del software, e consiglio vivamente la sua lettura: The Econ 101 Management Method

Il punto chiave, per me, è questo, citando Jeff: "L'uso responsabile delle metriche è importante tanto quanto raccoglierle in primo luogo."

12
Machado

Ciò che mi confonde con le metriche del codice è che non viene fatto di più. La maggior parte delle aziende riferisce sull'efficienza dei propri dipendenti, fornitori e sistemi in atto, ma nessuno sembra voler riferire sul codice. Concordo sicuramente con le risposte che affermano che più righe di codice sono una responsabilità, ma ciò che fa il tuo codice è più importante.

Lines Of Code: Come ho già detto, questa è una misura vitale e dovrebbe essere presa la più seriamente, ma ad ogni livello. Funzioni, classi, file e interfacce possono indicare il codice di tutto ciò che è difficile da mantenere e costoso a lungo termine. È infinitamente difficile confrontare le linee totali di codice rispetto a ciò che fa un sistema. Potrebbe essere qualcosa che fa molte cose e in quel caso ci saranno molte righe di codice!

Complessità: Questa misura è buona da fare su basi di codice su cui non hai lavorato e può darti una buona indicazione di dove si trovano le aree problematiche. Come utile aneddoto ho misurato la complessità su una delle mie basi di codice e l'area di massima complessità era quella che stavo impiegando più tempo quando avevo bisogno di cambiarla. Lavorare per ridurre la complessità ha comportato una notevole riduzione dei tempi di manutenzione. Se la gestione avesse queste misure a portata di mano, potrebbe pianificare iterazioni di refactoring o riprogettazioni di aree specifiche di un sistema.

Duplicazione del codice: Questa è una misura molto importante per quanto mi riguarda. La duplicazione del codice è un brutto segno e potrebbe indicare problemi profondi a bassi livelli della progettazione di un sistema o sviluppatori che stanno incollando copie, causando enormi problemi a lungo termine e sistemi non mantenibili.

Grafici di dipendenza La ricerca di dipendenze errate e dipendenze circolari è una misura importante nel codice. Ciò indica quasi sempre un design di alto livello errato che deve essere rivisto. A volte una dipendenza può assorbire molte altre inutili, perché qualcuno sta usando addNumber all'interno di una libreria di posta elettronica per fare i propri calcoli finanziari. Tutti sono scioccati quando la biblioteca di posta elettronica viene cambiata e le finanze si interrompono. Se tutto dipende da una cosa, può anche puntare a fare tutto - librerie difficili da mantenere e mal progettate.

Una buona misurazione ti dirà sempre che ogni caratteristica di un sistema ha un ingombro ridotto. Meno dipendenze, meno complessità, meno duplicazioni. Ciò indica un accoppiamento lento e un'elevata coesione.

11
Tjaart

Questo schifo "metriche del codice sorgente" non morirà MAI?

SLOC (Raw Source Lines of Code) è la metrica più antica, più semplice e più elementare che esista.

Originariamente Halstead ha proposto un sacco di metriche. Molte persone si sono divertite un sacco a scrivere programmi di misurazione fino a quando alcuni spoilsport non hanno fatto lo studio ovvio e hanno dimostrato che ogni singola metrica di Halstead era fortemente correlata direttamente con SLOC.

A quel punto, le metriche di Halstead sono state abbandonate, perché SLOC è sempre più facile da misurare.

8
John R. Strohm

Le metriche del codice sorgente per la garanzia della qualità mirano a due obiettivi:

  • scrivere codice con meno bug all'interno
  • scrivere codice per una facile manutenzione

Entrambi portano a scrivere il codice nel modo più semplice possibile. Questo significa:

  • brevi unità di codice (funzioni, metodi)
  • pochi elementi in ciascuna unità (argomenti, variabili locali, istruzioni, percorsi)
  • e molti altri criteri più o meno complessi (vedi Software metric in Wikipedia).
8
mouviciel

Per quanto ne so, il numero di bug trovati è direttamente correlato a righe di codice (probabilmente churn), linguaggio modulo, programmatore e dominio.

Non conosco altre metriche semplici e pratiche ben correlate con i bug.

Una cosa che mi piacerebbe fare è iniziare a gestire i numeri per diversi progetti su cui sto lavorando - Test Coverage :: kLOC, quindi discutere della "qualità percepita" per vedere se esiste una correlazione.

7
Paul Nathan

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 che tu misuri qualcosa a 98.6 ° F non significa nulla fino a quando non sai qual è la temperatura normale . La temperatura sopra è buona per la temperatura corporea ma davvero male per il gelato.

Le metriche comuni che possono essere utili sono:

  • Bug scoperti/settimana
  • Bug risolti/settimana
  • # Requisiti definiti/rilascio
  • # Requisiti implementati/rilascio

Le prime due misurano le tendenze. Stai trovando bug più velocemente di quanto tu possa risolverli? Due possibili risultati: forse abbiamo bisogno di più risorse per correggere i bug, forse dobbiamo smettere di implementare nuove funzionalità fino a quando non ci mettiamo al passo. I secondi due forniscono un quadro di quanto sei vicino a essere fatto. I team agili lo definiscono un grafico "burn down".

La complessità ciclomatica è una metrica interessante. Al suo concetto di base è il numero di percorsi di esecuzione univoci in una funzione/metodo. In un ambiente pesante di unit test questo corrisponde al numero di test necessari per verificare ogni percorso di esecuzione. Tuttavia, solo perché hai un metodo che ha una complessità ciclomatica di 96 non significa che è necessariamente un codice errato - o che devi scrivere 96 test per fornire una ragionevole sicurezza. Non è raro che il codice generato (tramite WPF o generatori di parser) crei qualcosa di così complesso. Può fornire un'idea approssimativa del livello di sforzo necessario per eseguire il debug di un metodo.

Bottom Line

Ogni misurazione effettuata deve avere le seguenti definizioni o è inutile:

  • Comprensione di ciò che è "normale". Questo può essere adattato per tutta la durata del progetto.
  • Una soglia al di fuori del "normale" in cui è necessario intraprendere una sorta di azione.
  • Un piano per gestire il codice quando viene superata la soglia.

Le metriche prese possono variare notevolmente da un progetto all'altro. Potresti avere alcune metriche che usi attraverso i progetti, ma la definizione di "normale" sarà diversa. Ad esempio, se un progetto ha scoperto una media di 5 bug/settimana e il nuovo progetto sta scoprendo 10 bug/settimana, ciò non significa necessariamente che qualcosa non va. Potrebbe essere che il team di test sia più meticoloso questa volta. Inoltre, la definizione di "normale" può cambiare nel corso della vita del progetto.

La metrica è solo un termometro, dipende da te.

7
Berin Loritsch

Il codice sorgente è una passività, non una risorsa. Tenendo presente questo, misurare le linee di codice è analogo al monitoraggio dei dollari spesi durante la costruzione di una casa. Deve essere fatto se si vuole rimanere sotto budget, ma non si deve necessariamente pensare 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 righe 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.

6
Larry Coleman

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 quasi il 100% di copertura del codice di test che utilizza il minor numero di righe di codice necessarie per eseguire il lavoro e tuttavia abbastanza flessibile da resistere alle modifiche.

4
Xenohacker

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 (oltre 70 persone nella nostra azienda, altre 30+ presso i nostri clienti) che utilizzava i conteggi KLOC come unica misura delle prestazioni di team e individui.

Per il nostro impegno su Y2K (ti dice quanto tempo fa :)) abbiamo fatto una grande ripulitura della sezione del codice di cui il mio team era responsabile. Alla fine siamo usciti scrivendo circa 30.000 righe di codice, non male 3 mesi di lavoro per 5 persone. Alla fine abbiamo anche eliminato altre 70.000 righe di codice, un ottimo lavoro per 3 mesi di lavoro, in particolare combinato con il nuovo codice.

Risultato finale per il trimestre: -40.000 righe di codice. Durante la revisione delle prestazioni dopo il 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 dimostrato che avevamo prodotto -40.000 righe di codice), che avrebbe portato tutti noi a essere elencati come sottoperformati e aggirati per promozioni, formazione, aumento di stipendio, ecc., se il responsabile del progetto e il team addetto al controllo qualità non fossero intervenuti e ottenuto il rimprovero annullato e sostituito da un encomio.

Qualche mese dopo (cose del genere 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.

4
jwenting

Sono sorpreso che nessuno abbia menzionato la dichiarazione/copertura decisionale dei test unitari (percentuale di codice esercitato dai test unitari) ancora.

La copertura del codice è utile in quanto sai quale percentuale dell'applicazione non fallisce catastroficamente; con il resto della sua utilità dipende dalla qualità dei test unitari.

2
StuperUser

Queste non sono molto utili assolute metriche in termini di progresso, ma possono essere usate per dare un'idea generale dello stato del codice.

In particolare la complessità ciclomatica ho trovato utile in termini di visualizzazione di quanto sia modulare una data base di codice. Generalmente si desidera una bassa complessità poiché ciò significa che il numero di fonti per modulo è basso e ci sono molti moduli.

1
user1249

Più piccolo è, meglio è, di solito. Riguarda gli strumenti SCM, non il codice in sé, ma è una metrica molto misurabile. Più piccolo è il commit, più facile è vedere ogni cambiamento come un'unità atomica; più è facile ripristinare modifiche specifiche e individuare quando le cose si sono rotte.

Finché nessun commit interrompe la compilazione ...

1
Assaf Lavie

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 Java che controlla continuamente le metriche (tra le altre cose) del mio codice rispetto un insieme di regole che abbiamo definito e contrassegna i luoghi in cui il mio codice non è conforme a tali regole. Durante lo sviluppo del codice, mi dice in tempo reale se i miei metodi diventano troppo lunghi, complessi o accoppiati permettendomi di fare un passo indietro e pensa a refactoring a qualcosa di meglio.

Gli sviluppatori sono completamente liberi di infrangere 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 le recensioni di QA/Code

La prima cosa che faccio generalmente quando eseguo una revisione del codice è controllare la copertura 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 del 100% purché il codice importante sia ben testato. Quindi la percentuale coperta è in qualche modo insignificante, ma lo 0% si distingue come un pollice dolente come qualcosa che voglio guardare attentamente.

Controllo anche quali parametri concordati dal team sono stati "rotti", se presenti, per vedere se sono d'accordo con lo sviluppatore che era OK o se posso suggerire modi per migliorarlo. Avere queste metriche di sviluppo concordate nel nostro team per la scrittura di nuovo codice ha fatto grandi progressi nel migliorare il nostro codice. Scriviamo metodi monolitici molto meno e ora siamo molto meglio con principio di responsabilità singola .

Miglioramenti di tendenza al codice legacy Abbiamo un sacco di codice legacy che vorremmo migliorare. Le metriche in qualsiasi momento sono abbastanza inutili, ma ciò che è importante per noi è che nel tempo la copertura del codice aumenta e cose come la complessità e l'accoppiamento diminuiscono. Pertanto, le nostre metriche sono collegate al nostro server di integrazione continua che ci consente di guardare nel tempo per assicurarci di essere sulla strada giusta.

Conoscere una nuova base di codice Circa l'unica volta che uso mai righe di metrica del codice sorgente è quando guardo una base di codice che non conosco con. Mi permette di valutare rapidamente le dimensioni approssimative del progetto rispetto alle altre con cui ho lavorato. Utilizzando altre metriche posso anche avere un'idea più approssimativa della qualità del progetto.

Le cose chiave sono usare le metriche come punti di partenza per tendenze, discussioni o vie da seguire e non gestirle religiosamente per ottenere cifre esatte. Ma credo fermamente che possano aiutarti a migliorare il codice giusto se usato correttamente.

1
Chris Knight

Lavoro spesso su un gigantesco pacchetto C++, e quando cerco un codice problematico vale la pena refactoring di Cyclomatic Complexity o horrible FanIn/FanOut sono di solito delle buone bandiere rosse da cercare. Risolvere i problemi di solito porterà a miglioramenti nell'intera base di codice.

Naturalmente questi numeri possono solo servire da suggerimento su ciò che varrebbe la pena guardare. Rendere questa soglia difficile dopo la quale fallire una build o rifiutare un commit sarebbe ridicolo.

1
Benjamin Bannier

D: Quali sono le metriche utili da acquisire per il codice sorgente?

Per le imprese:

A: Numero di ore-uomo

Per il supervisore del programmatore:

A: Non importa. Facciamo tutto oggi

Per l'autostima del programmatore:

A: Numero di SLOC (righe di codice sorgente)

Per la madre del programmatore:

A: Mangia più di questi morbidi involtini francesi e bevi il tè

continua nei commenti qui sotto ...

0
Genius