Metriche obiettive per la qualità del software [chiuso]

Questa è un'idea pericolosa. I proxy "oggettivi" per la qualità portano direttamente ai premi della direzione e gli sviluppatori perseguiranno queste metriche a scapito della qualità effettiva.

Questa è la legge delle conseguenze non intenzionali.

La qualità, sebbene importante, è solo un piccolo aspetto del software. Funzionalità e valore creati dal software sono molto, molto più importanti della qualità.

Tutte le metriche portano all'attività per ottimizzare la metrica. Questo, a sua volta, ha conseguenze che potrebbe non piacerti molto.

Il software è molto complesso. È difficile capire quanto sia davvero complesso.

Anche cose così "ovvie" come la copertura del codice di test unitario possono perdere tempo. Arrivare al 100% potrebbe richiedere la creazione di test che sono in realtà più complessi del codice banale da testare. Raggiungere una copertura del 100% può comportare costi inaccettabili. [L'alternativa per codice banale, piccolo, usato raramente è test-by-inspection. Ma questo non si adatta al gioco delle metriche del 100%.]

Un altro esempio è la complessità ciclomatica. È una delle migliori misure di qualità del codice. Ma può essere giocato creando molte piccole funzioni che potrebbero essere più difficili da leggere (e più difficili da mantenere) rispetto a una funzione più grande. Si finisce con le revisioni del codice in cui si concorda che potrebbe non essere molto leggibile, ma soddisfa la soglia di complessità.

I also wonder if this a dangerous idea, that if objective proxies for quality become popular that business pressures will cause developers to pursue these metrics at the expense of the overall quality (those aspects of quality not measured by the proxies).

Bingo e no "se" a riguardo. Si chiama "Measurement Dysfunction" ed è stato osservato e scritto molte volte su Joel ha scritto un articolo su di esso nel 2002 riferimento a un libro di un professore di Harvard.

Ciò non significa che tali parametri siano inutili, solo che uno non dovrebbe mai basare esplicitamente incentivi o politiche su tali misure proxy. Se vuoi migliorare la qualità, una metrica proxy con un valore molto negativo è probabilmente un buon punto di partenza. Ma non puoi concludere che la qualità sia buona solo perché tutte le tue metriche hanno grandi valori.

What I'm interested in is a deeper form of quality related to the network (or graph) of types and their inter-relatedness, that is, what types does each type refer to, are there clearly identifiable clusters of interconnectivity relating to a properly tiered architecture, or conversely is there a big 'ball' of type references ('monolithic' code).

Questo suona come fan-in e fan-out. Fan-in conta il numero di moduli che chiamano un determinato modulo e fan-out conta il numero di moduli chiamati da un dato modulo. Un segnale di avvertimento da usare sarebbe costituito da moduli con un grande fan-in e un grande fan-out, in quanto ciò potrebbe indicare un design scadente e un obiettivo chiave per il refactoring o la riprogettazione.

Also the size of each type and/or method (e.g. measured in quantity of Java byte code or .Net IL) should give some indication of where large complex algorithms have been implemented as monolithic blocks of code instead of being decomposed into more manageable/maintainable chunks.

Una semplice misura sarebbe linee di codice. Potresti suddividerlo in linee di codice totali attraverso l'intero progetto e linee di codice per modulo (magari usando moduli di dimensioni diverse). È possibile utilizzare questo come un indicatore di avviso che indica che è necessario rivedere particolari moduli. Un libro su misurazioni e metriche sulla qualità del software illustra alcuni lavori che indicano che la relazione tra i tassi di difetto e la dimensione del modulo è curvilinea , dove il difetto medio per KSLOC viene fornito con moduli con una dimensione tra 175 e 350 SLOC.

Qualcosa di un po 'più complesso sarebbe la complessità ciclomatica, che è progettata per indicare la testabilità, la comprensibilità e la manutenibilità di un sistema. La complessità ciclomatica conta il numero di percorsi indipendenti attraverso un'applicazione o un modulo. Il numero di test, e quindi lo sforzo necessario per produrre ed eseguire i test, è strongmente correlato alla complessità ciclomatica.

The exact threshold/decision points between high and low quality would I suspect be subjective, e.g. since by maintainability we mean maintainability by human programmers and thus the functional decomposition must be compatible with how human minds work.

Non sono sicuro che sia così.

Ad esempio, c'è stata una ricerca che suggerisce che la memoria di lavoro di un essere umano può contenere solo 7 più / meno 2 oggetti . Questo è probabilmente di interesse per misurare fan-in e fan-out - se sto lavorando in un modulo, ed è collegato a più di ~ 7 altri moduli, probabilmente non sarò in grado di tenere traccia di esattamente cosa quelli altri moduli sono nella mia testa.

C'è stato anche un lavoro sulla correlazione dei difetti con le metriche come la complessità ciclomatica. Dal momento che vuoi minimizzare i difetti nel tuo sistema, puoi identificare i punti che richiedono uno sforzo maggiore di test o di refactoring, come identificato da una elevata complessità ciclomatica.

I also wonder if this a dangerous idea, that if objective proxies for quality become popular that business pressures will cause developers to pursue these metrics at the expense of the overall quality (those aspects of quality not measured by the proxies).

Questo è il caso di qualsiasi misura o metrica. Devono essere usati per capire il sistema e prendere decisioni informate. Mi viene in mente la frase "non puoi gestire ciò che non puoi misurare". Se si desidera un software di alta qualità, sono necessarie alcune misurazioni e metriche per valutare tale qualità. Tuttavia, c'è un rovescio della medaglia su questo. Non puoi gestire esclusivamente dai numeri. Puoi utilizzare i numeri per prendere decisioni informate, ma non puoi prendere una decisione solo perché i numeri lo dicono.

Ci sono metriche o proxy per molte delle qualità che ti interessano:

1. Linee di codice
2. Ventola, fan out
3. Tasso di errore per 1000 righe di codice
4. Complessità ciclomatica
5. Copertura del codice
6. Copertura del punto di decisione
7. Rapporto degli errori riparati / introdotti dalle attività di manutenzione
8. Analisi dei punti di funzione

Ci sono alcuni problemi con tutti questi elementi:

1. Il lavoro svolto per ottimizzare la metrica - una tendenza universale; massicciamente aggravato se una delle metriche viene utilizzata come base per la valutazione o la ricompensa per team o individui.
2. Non sono a conoscenza di alcuna metrica priva di contesto. Ciò implica che non è possibile effettuare confronti tra negozi, ma solo all'interno dei negozi, nel tempo. Le metriche derivanti da tali confronti sono ancora valide: "stiamo producendo codice più correttamente adesso rispetto a un anno fa".

L'effetto complessivo di questi problemi è che le metriche come queste sono probabilmente valide solo all'interno di una cultura più ampia - come TQM, garanzia di qualità (non controllo), miglioramento continuo, kaizan ecc. È necessario definire gli elementi di sia la cultura, sia il modo in cui deve cambiare. Se hai una definizione di questi, le metriche come queste diventano strumenti essenziali per aiutare a migliorare la qualità del codice, le pratiche di lavoro, la produttività, ecc. Senza questo contesto più ampio, le metriche genereranno lavoro per ottimizzare la metrica; diventerà lo strumento del beancounter per aumentare la produttività e ridurre i costi; e diventerà un ostacolo per il giocatore di sviluppo.

Potresti essere ossessionato dalle metriche, o potresti essere ossessionato con le persone migliori, gli strumenti, le pratiche per l'ingegneria e il controllo qualità che puoi permetterti. Sarei molto più felice di avere diversi geni paranoici del QA che hanno letto "Fooled by Randomness" e che amano automatizzare di un mucchio di rapporti ben formattati con numeri.

C'è questo problema fondamentale con le metriche.

Praticamente tutte le metriche proposte sono state mostrate, nel mondo reale sul codice reale, per essere strongmente o strongmente correlate con SLOC raw (linee di codice sorgente).

Questo è ciò che ha ucciso le metriche di Halstead, negli anni '70. (Per caso, un giorno, intorno al 1978, ho parlato di un nuovo dottorato sulle metriche di Halstead, in cui lo ha sottolineato.)

Più recentemente, la complessità ciclomatica di McCabe si è dimostrata strongmente correlata con la SLOC grezza, al punto che il ragazzo che ha fatto lo studio si è chiesto ad alta voce se la metrica di McCabe ci avesse detto qualcosa di utile.

Da decenni sappiamo che i grandi programmi avevano più probabilità di avere problemi di quelli piccoli. Sappiamo da decenni che le subroutine di grandi dimensioni erano più probabili avere bug rispetto a quelle piccole. Perché abbiamo bisogno di metriche arcane per dirci questo, quando guardare quattro pagine di stampa sparse su un tavolo dovrebbe essere abbastanza convincente?

Considerate tutte le altre risposte qui, mi sento piuttosto stupido con questo piccolo. Dai un'occhiata a Crap4j , che tenta di classificare i metodi in java in base a quanto puzzano. (Il progetto sembra abbandonato.)

Utilizza una combinazione di complessità ciclomatica e copertura del test. Come ogni altra metrica, è giocabile.