Quali sono metriche utili per il codice sorgente? [chiuso]

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

In che modo le metriche, come ad esempio le righe di codice (eseguibili?) O la complessità ciclomatica, possono aiutare a garantire la qualità o in che modo sono utili in generale per il processo di sviluppo del software?

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

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

Una visita dalla cameriera delle metriche

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: il metodo di gestione 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 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.

Linee di codice: come ho già detto, questa è una misura vitale e dovrebbe essere presa più seriamente, ma ad ogni livello. Funzioni, classi, file e interfacce possono indicare un codice 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 misurazione è utile da eseguire 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 a portata di mano queste misurazioni, 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 Trovare 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 tutte le librerie che sono 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.

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.

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 metrica del software in Wikipedia).

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

Non conosco nessun'altra metrica semplice e pratica ben correlata 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.

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 fino a quando non si conosce 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.

Linea di fondo

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 utilizzi in tutti 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.

Il codice sorgente è una responsabilità, non una risorsa. Con questo in mente, 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.

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 test della copertura del codice che utilizza il minor numero 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 (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 singoli 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 un cattivo lavoro di 3 mesi 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 hanno detto che la società stava rivedendo i loro standard di produttività e avevamo assunto un team di esperti per creare un nuovo sistema basato sull'analisi dei punti di funzione.

Sono sorpreso che nessuno abbia mai menzionato la Dichiarazione / Copertura Decisionale dei test unitari (percentuale di codice esercitato dai test unitari).

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.

Più piccolo è, meglio è, di solito. Si tratta degli strumenti SCM, non del 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 ...

Queste non sono metriche assolute molto utili in termini di progresso, ma possono essere utilizzate 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.

Lavoro spesso su un gigantesco pacchetto C ++, e quando cerco un codice problematico che valga la pena rifattorizzare la complessità ciclica o l'orribile FanIn / FanOut di solito sono 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.

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 una serie di regole che abbiamo definito e contrassegna i luoghi in cui il mio codice non lo fa rispettare 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 rifattorizzarlo in 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 revisioni di qualità / codice

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 "non funzionanti", 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 contribuito notevolmente a migliorare il nostro codice. Scriviamo metodi molto meno monolitici e ora siamo molto meglio con il principio della singola responsabilità .

Tendenze di tendenza nel codice legacy Abbiamo un sacco di codice legacy in circolazione 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 in cui utilizzo linee di metrica del codice sorgente è quando guardo una base di codice che non conosco. 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.

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

Per affari:

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 ...

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 sia d'aiuto!