Metriche oggettive per la qualità del software [chiuso]

Esistono vari tipi di qualità che possono essere misurati nei prodotti software, ad esempio idoneità allo scopo (ad es. Uso finale), manutenibilità, efficienza. Alcuni di questi sono in qualche modo soggettivi o specifici del dominio (ad esempio, i buoni principi di progettazione della GUI possono variare a seconda delle culture o dipendono dal contesto di utilizzo, si pensi all'utilizzo militare rispetto al consumo).

Ciò che mi interessa è una forma più profonda di qualità correlata alla rete (o al grafico) dei tipi e alla loro interrelazione, ovvero a quali tipi fa riferimento ciascun tipo, ci sono cluster chiaramente identificabili di interconnettività relativi a un architettura a più livelli, o viceversa esiste una grande "sfera" di riferimenti di tipo (codice "monolitico"). Anche le dimensioni di ciascun tipo e / o metodo (ad esempio misurate in quantità di codice byte Java o .Net IL) dovrebbero fornire indicazioni su dove sono stati implementati algoritmi complessi di grandi dimensioni come blocchi monolitici di codice anziché essere scomposti in più gestibili / gestibili pezzi.

Un'analisi basata su tali idee potrebbe essere in grado di calcolare metriche che sono almeno un proxy per la qualità. Sospetto che i punti soglia / decisione esatti tra alta e bassa qualità siano soggettivi, ad esempio poiché per manutenibilità intendiamo manutenibilità da parte dei programmatori umani e quindi la decomposizione funzionale deve essere compatibile con il modo in cui funzionano le menti umane. Pertanto mi chiedo se ci possa mai essere una definizione matematicamente pura della qualità del software che trascenda tutto il software possibile in tutti gli scenari possibili.

Mi chiedo anche se questa sia un'idea pericolosa, che se i proxy oggettivi per la qualità diventano popolari, le pressioni del business indurranno gli sviluppatori a perseguire questi parametri a spese della qualità complessiva (quegli aspetti della qualità non misurati dai proxy).

Un altro modo di pensare alla qualità è dal punto di vista dell'entropia. L'entropia è la tendenza dei sistemi a ritornare dagli stati ordinati a stati disordinati. Chiunque abbia mai lavorato su un mondo reale, un progetto software di medie e grandi dimensioni apprezzerà il grado in cui la qualità della base di codice tende a deteriorarsi nel tempo. Le pressioni aziendali generano generalmente cambiamenti che si concentrano su nuove funzionalità (eccetto dove la qualità stessa è il principale punto di forza, ad esempio nel software avionico), e l'erosione della qualità attraverso problemi di regressione e funzionalità "scarpata" dove non si adatta bene una prospettiva di qualità e manutenzione. Quindi, possiamo misurare l'entropia del software? E se sì, come?

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

Questa è la legge delle conseguenze indesiderate.

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 conducono all'attività per ottimizzare la metrica. Ciò, a sua volta, ha conseguenze che potrebbero non piacerti davvero.

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

Anche cose "ovvie" come la copertura del codice unit test possono far perdere tempo. Arrivare al 100% potrebbe richiedere la creazione di test che sono in realtà più complessi del codice banale che si sta testando. Arrivare al 100% di copertura può comportare un costo inaccettabile. [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 si può giocare creando molte piccole funzioni che potrebbero essere più difficili da leggere (e più difficili da mantenere) di una funzione più grande. Si finisce in revisioni del codice in cui si accetta che potrebbe non essere molto leggibile ma soddisfa la soglia di complessità.

Mi chiedo anche se questa sia un'idea pericolosa, che se i proxy oggettivi per la qualità diventano popolari, le pressioni del business indurranno gli sviluppatori a perseguire questi parametri a spese della qualità complessiva (quegli aspetti della qualità non misurati dai proxy).

Bingo e nessun "se" al riguardo. Questo si chiama "Disfunzione di misurazione" ed è stato osservato e scritto molte volte Joel ha scritto un articolo su di esso nel 2002 riferendosi a un libro di un professore di Harvard.

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

Ciò che mi interessa è una forma più profonda di qualità correlata alla rete (o al grafico) dei tipi e alla loro interrelazione, ovvero a quali tipi fa riferimento ciascun tipo, ci sono cluster chiaramente identificabili di interconnettività relativi a un architettura a più livelli, o viceversa esiste una grande "sfera" di riferimenti di tipo (codice "monolitico").

Questo suona come fan-in e fan-out. Il fan-in conta il numero di moduli che chiamano un determinato modulo e il fan-out conta il numero di moduli chiamati da un determinato modulo. Un segnale di avvertimento da utilizzare sarebbero i moduli con un grande fan-in e un grande fan-out, poiché ciò potrebbe indicare un design scadente e un obiettivo chiave per il refactoring o la riprogettazione.

Anche le dimensioni di ciascun tipo e / o metodo (ad esempio misurate in quantità di codice byte Java o .Net IL) dovrebbero fornire indicazioni su dove sono stati implementati algoritmi complessi di grandi dimensioni come blocchi monolitici di codice anziché essere scomposti in più gestibili / gestibili pezzi.

Una misurazione semplice sarebbe linee di codice. È possibile suddividerlo in righe di codice totali nell'intero progetto e righe di codice per modulo (magari utilizzando moduli di dimensioni diverse). È possibile utilizzare questo come indicatore di avviso che indica che è necessario rivedere determinati moduli. Un libro sulle misure e le metriche della qualità del software discute di alcuni lavori che indicano che la relazione tra i tassi di difetto e le dimensioni del modulo è curvilinea, in cui il difetto medio per KSLOC viene fornito con moduli con dimensioni comprese tra 175 e 350 SLOC.

Qualcosa di un po 'più complesso sarebbe la complessità ciclomatica, 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, è fortemente correlato alla complessità ciclomatica.

Sospetto che i punti soglia / decisione esatti tra alta e bassa qualità siano soggettivi, ad esempio poiché per manutenibilità intendiamo manutenibilità da parte dei programmatori umani e quindi la decomposizione funzionale deve essere compatibile con il modo in cui funzionano le menti umane.

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 oggetti più / meno 2 . Questo è probabilmente interessante per misurare il fan-in e il fan-out - se sto lavorando in un modulo, ed è collegato a più di ~ 7 altri moduli, probabilmente non sarò in grado di tenere traccia esattamente di cosa altri moduli sono nella mia testa.

C'è stato anche un lavoro sul mettere in relazione i difetti con metriche come la complessità ciclomatica. Dal momento che si desidera ridurre al minimo i difetti del sistema, è possibile identificare i punti che richiedono più prove di sforzo o refactoring, come identificato da un'elevata complessità ciclomatica.

Mi chiedo anche se questa sia un'idea pericolosa, che se i proxy oggettivi per la qualità diventano popolari, le pressioni del business indurranno gli sviluppatori a perseguire questi parametri a spese della qualità complessiva (quegli aspetti della qualità non misurati dai proxy).

Questo è il caso di qualsiasi misura o metrica. Devono essere utilizzati per comprendere 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 misure e metriche per valutare tale qualità. Tuttavia, c'è un rovescio della medaglia in questo. Non puoi gestirlo esclusivamente con i numeri. Puoi usare i numeri per prendere decisioni informate, ma non puoi prendere una decisione solo perché i numeri lo dicono.

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

1. Linee di codice
2. Fan in, fan out
3. Tasso di errore per 1000 righe di codice
4. Complessità ciclomatica
5. Copertura del codice
6. Copertura del punto decisionale
7. Rapporto tra errori corretti / introdotti dalle attività di manutenzione
8. Analisi del punto di funzione

Ci sono alcuni problemi con tutti questi elementi:

1. Lavoro svolto per ottimizzare la metrica: una tendenza universale; esacerbato in modo massiccio se una qualsiasi delle metriche viene utilizzata come base per la valutazione o la ricompensa per team o individui.
2. Non sono a conoscenza di metriche libere dal contesto. Ciò implica che non è possibile alcun confronto tra i negozi - solo all'interno dei negozi, nel tempo. Le metriche derivanti da tali confronti sono ancora preziose: "stiamo producendo codice più correttamente ora rispetto a un anno fa".

L'effetto totale di questi problemi è che metriche come queste sono probabilmente preziose solo all'interno di una cultura più ampia - come TQM, garanzia di qualità (non controllo), miglioramento continuo, kaizan ecc. È necessario definire elementi di entrambe le culture e come deve cambiare. Se ne hai una definizione, allora 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 gioco da parte dello staff di sviluppo.

Potresti essere ossessionato dalle metriche o potresti essere ossessionato dalle persone, dagli strumenti, dalle pratiche migliori per l'ingegneria e il QA che ti puoi permettere. Sarei molto più felice di avere diversi geni paranoici del QA che hanno letto 'Fooled by Randomness' e che amano automatizzare rispetto a un mucchio di rapporti ben formattati con numeri.

C'è questo problema fondamentale con le metriche.

Praticamente tutte le metriche proposte hanno dimostrato, nel mondo reale sul codice reale, di essere fortemente o fortemente correlate con lo SLOC grezzo (linee di codice sorgente).

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

Più di recente, la complessità ciclomatica di McCabe ha dimostrato di essere fortemente correlata con la SLOC grezza, al punto che il ragazzo che ha condotto lo studio si è chiesto ad alta voce se la metrica di McCabe ci ha detto qualcosa di utile.

Sappiamo da decenni che i grandi programmi avevano maggiori probabilità di avere problemi rispetto a quelli piccoli. Sappiamo da decenni che le grandi subroutine erano più propense ad avere bug che a piccole. Perché abbiamo bisogno di metriche arcane per dircelo, quando guardare quattro pagine di stampanti distribuite su un tavolo dovrebbe essere abbastanza convincente?

Date tutte le altre risposte qui, mi sento un po 'sciocco con questo piccolo. Dai un'occhiata a Crap4j , che cerca di classificare i metodi in java di quanto puzzano. (Il progetto sembra abbandonato.)

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