Come fai a sapere se il software è buono o cattivo in base a parametri empirici?

Non lo fai.

La qualità del software è davvero difficile da misurare obiettivamente. È abbastanza difficile che non ci sia una soluzione. Mi sto trattenendo in questa risposta per dilungarmi sulla questione se possa esserci una soluzione, ma semplicemente sottolineare perché definirne uno sarebbe davvero difficile.

Ragionamento per status quo

Come ha sottolineato Kilian Foth, se esistesse una semplice misura per il software "buono", lo useremmo tutti e tutti lo richiederebbero.

Ci sono progetti in cui i manager hanno deciso di applicare determinate metriche. A volte funzionava, a volte no. Non sono a conoscenza di correlazioni significative. I software di sistema particolarmente critici (pensano che aerei, automobili, ecc.) Abbiano molti requisiti di metrica per "assicurare" la qualità SW - non sono a conoscenza di studi che dimostrino che questi requisiti in realtà producono una qualità superiore, e ho esperienze personali per contrario.

Ragionamento da controspionaggio

Già accennato da Kilian già, e più in generale formulato come "ogni metrica può e verrà giocata".

Che cosa significa suonare una metrica? È un gioco divertente per gli sviluppatori: assicuri che i valori delle metriche siano davvero buoni, mentre fai cose davvero di merda.

Supponiamo che tu misuri i difetti per LOC. Come lo suonerò? Facile - basta aggiungere altro codice! Crea codice stupido che si traduce in una non operazione su 100 linee e improvvisamente hai meno difetti per LOC. Meglio di tutti: hai effettivamente diminuito la qualità del software in questo modo.

Le carenze degli strumenti sono abusate, le definizioni sono estese al massimo, sono inventati modi completamente nuovi .. fondamentalmente, gli sviluppatori sono persone davvero intelligenti e se hai un solo sviluppatore del tuo team che si diverte a giocare le metriche, allora le tue metriche saranno discutibile.

Questo non vuol dire che le metriche siano sempre negative, ma l'atteggiamento della squadra nei confronti di queste metriche è cruciale. In particolare, ciò implica che non funzionerà bene per qualsiasi rapporto di fornitore / subappaltatore di terze parti.

Ragioni del targeting errato

Quello che vuoi misurare è la qualità del software. Quello che misuri è una o più metriche.

C'è un divario tra ciò che misurate e ciò che credete che vi dirà. Questo divario è persino enorme.

Succede sempre in tutti i tipi di aziende intorno a noi. Decisioni mai viste basate su KPI (indicatori chiave di prestazione)? È lo stesso problema: vuoi che un'azienda funzioni bene, ma misura qualcos'altro.

Ragionamento in base alla quantificabilità

Le metriche possono essere misurate. Qual è l'unica ragione per cui ci occupiamo di loro. La qualità del software, tuttavia, si estende ben oltre queste entità misurabili e ha molto, molto difficile da quantificare: quanto è leggibile il codice sorgente? Quanto è estensibile il tuo design? Quanto è difficile per i nuovi membri del team essere integrati? ecc. ecc.

Valutare la qualità del software solo tramite metriche e chiudere un occhio sulle parti di qualità che non è possibile quantificare non funzionerà sicuramente.

modifica:

Sommario

Permettetemi di far notare che quanto sopra è tutto sul giudizio oggettivo se il software è buono o cattivo in base alle metriche. Ciò significa che non sta dicendo nulla riguardo se e quando applicare le metriche.

In realtà, questa è un'implicazione unidirezionale: le metriche errate implicano un codice errato. Unidirezionale significa che il codice errato non garantisce le metriche cattive, né le buone metriche garantiscono un buon codice. D'altra parte, questo di per sé significa che puoi applicare le metriche per giudicare un pezzo di software - quando tenga presente questa implicazione in mente.

Misurate il software A e le metriche risultano davvero pessime. Quindi puoi essere certo che la qualità del codice è cattiva. Misurate il software B e le metriche sono ok, quindi non avete alcun indizio sulla qualità del codice. Non lasciatevi ingannare nel pensare che "le metriche sono buone = codice buono" quando è veramente solo "codice buono = > metrica buona".

In sostanza, puoi utilizzare le metriche per trovare problemi di qualità, ma non la stessa qualità.

Sì, puoi dire che il codice ha problemi di qualità esaminando le metriche in una certa misura.

Più in particolare, esegui uno strumento di analisi della complessità sulla base di codice e avrai un'idea se il codice è buono o cattivo.

Ad esempio, potresti eseguire monitor di origine .

Ciò che ti dirà è quanto sia complesso il codice. Posso dirti che ogni sistema problematico che ho sperimentato aveva numeri cattivi. Complessità da 10 a 100 di metodi ben oltre i limiti accettabili. Numeri terribili Terribile complessità, nidificazione, profondità, ecc. Questo porterà a molti problemi, a un alto tasso costante di difetti, a difficili modifiche, senza rompere qualcos'altro, ecc.

Un'altra cosa sono i difetti. Nel tempo il sistema dovrebbe stabilizzarsi. I difetti idealmente nuovi dovrebbero tendersi verso zero o appiattirsi verso un numero basso, il che significa che i difetti attuali e nuovi dovrebbero diminuire nel tempo.

La trama dovrebbe apparire in questo modo:

Difetti nel tempo

Serimangonocostantioaumentano,ilsoftwarenonèbuono.Ituoisoli4mesiin,quindivorreidargliqualchealtromeseperunanno.Dopo6mesiaunanno,sehaiavutounflussocostantedidifetti,alloraèdipessimaqualità.Iltuoteamhasviluppatoun'altra palla di fango .

Prossimi test. Li hai? Se no allora meno qualità, più bug, più churn. Se li hai, le metriche come la copertura del codice sono buone per farti un'idea di quanto è coperto il codice, ma non misurerà la qualità . Ho visto grandi numeri di copertura del codice, ma i test effettivi erano pessimi. Non stavano testando alcun comportamento o funzionalità del sistema. Gli sviluppatori li stavano semplicemente scrivendo per migliorare i numeri delle metriche per la gestione. Quindi devi avere test e devono essere buoni. Le metriche di copertura del codice in se stesse non sono un indicatore di qualità.

Recensioni del codice, le stai facendo? In caso contrario, meno qualità. Questo è particolarmente importante con gli sviluppatori junior. Se stai facendo agile, aggiungi un'attività di revisione del codice alla tua storia chiamata "revisione del codice". Se la direzione desidera tenere traccia dei numeri, è necessario uno strumento che tenga traccia delle recensioni come Crucible . Penso che i numeri di revisione del codice o le metriche non siano così importanti qui oltre al fatto che dovrebbero far parte del processo. Non tutti i controlli richiedono una revisione. Tuttavia, le recensioni possono aiutare a garantire che le persone non stiano reinventando la ruota o scrivendo codice che altri non possono comprendere e / o mantenere.

Infine, dovrai solo valutare il codice, nessuna metrica ti aiuterà. Ogni progetto di codice problematico aveva queste qualità:

• Strutture dati scadenti. Tutto è una stringa o XML è passato ovunque e analizzato ovunque, oggetti di dio o inutilmente complessi o strutture dati generiche, nessun modello di dominio.
• Mancanza di organizzazione o struttura, qualsiasi progetto non banale dovrebbe avere qualche divisione o stratificazione che separa la logica. Avere un guarda qui ... Se non vedi questo tipo di organizzazione o separazione (mescolando la logica ovunque), allora il sistema sarà più difficile da mantenere e capire.
• sulle astrazioni. A volte il contrario è vero, il sistema è finito astratta. Se tutto è un'interfaccia e una classe astratta, o tu devono navigare attraverso una tonnellata di classi di tipo "wrapper" di classe, il la qualità sarà negativa perché i nuovi sviluppatori non saranno in grado di navigare attraverso l'oggetto bloat.
• Codice difficile da capire. Se sei uno sviluppatore esperto e se lo sei guardando un codice così difficile da capire, avrà qualità i problemi. Il mio parametro personale è che se guardo il codice e questo è difficile seguirmi o farmi sentire stupido, o mi sento come se stessi sprecando un sacco di cicli cerebrali per capire la logica, quindi è un codice cattivo. Se gli sviluppatori esperti hanno difficoltà a seguirli, allora immagina come sarà per i nuovi sviluppatori. Introdurranno problemi.

Il mio consiglio sarebbe eseguire un'analisi di complessità sul codice. Non condividere i risultati, segui invece i risultati fai qualche indagine indipendente (guarda il codice) e stabilisci la salute generale del codice base. Da questo, forma un piano d'azione e prova a correggere alcune delle aree complesse del codice.

La cosa triste con le metriche è che potresti finire per migliorare i valori risultanti delle tue metriche, ma non la qualità che si intende misurare da loro ...

In Visual Studio, c'è un'impostazione per considerare gli avvertimenti del compilatore come errori. Ora alcune persone non capiscono gli avvertimenti e, per ottenere il codice compilato, useranno semplici trucchi (come "pragma disable warning" o aggiungendo una parola chiave "new" a una funzione / proprietà che nasconde un membro non virtuale di una base classe).

Se hai accesso al codice sorgente, puoi eseguire analisi del codice statico. Per i progetti .Net, puoi utilizzare per es. FxCop o ReSharper InspectCode. Se utilizzati correttamente dal team di sviluppo, gli strumenti contribuiranno a migliorare la qualità. Ma naturalmente, alcune "correzioni" per rimuovere gli avvertimenti senza comprenderle sono possibili.

Potresti esaminare i test automatici / UnitTests: quanto è buona la copertura del codice? Ma la copertura da sola non ti dirà se i test in realtà controllano il codice, o lo fanno eseguire una sola volta.

Cercare un'alta qualità è un atteggiamento che può essere supportato da molti strumenti e dalle loro metriche, ma le metriche senza l'atteggiamento degli sviluppatori non aiutano.

Una cosa che dovresti guardare oltre a raccogliere una metrica come l'iniezione di un difetto è capire la fonte dei difetti. Spesso è legato alle specifiche.

Fondamentalmente, è un errore nella specifica, un'ambiguità nella speificazione, lasciata alla decisione degli impianti o si tratta di un bug nell'implementazione.

Un approccio più qualitativo è chiedere se il software è utile? Se guardi bene puoi trovare difetti in qualsiasi software. Tuttavia, se funziona abbastanza bene per guadagnare denaro, allora potrebbe non essere così male.

In basso, non c'è un modo per saperlo.

Per la domanda originale (prima della risposta filosofica): che cosa dovrebbe fare il prodotto e lo fa? La misurazione in base al conteggio / densità dei difetti non è sufficiente. Non saprei dire se fosse una libreria o un'applicazione, quanto è grande il codice base, quanto è grande il dominio del problema, né quale sia la gravità dei difetti. Ad esempio, non gestire uno dei 123 formati di input potrebbe essere un difetto banale o uno stopper, a seconda dell'importanza del formato non gestito correttamente. E meglio di niente è uno standard elevato.

Assunzione che faccio per questa domanda: Esiste una differenza tra codice e software. Definisco il software come ciò che un client / utente usa per risolvere un problema, mentre il codice è il materiale da costruzione del software.

Il software può essere misurato solo in modo soggettivo. Cioè, la metrica che conta per il software è se le persone lo usano per risolvere un problema. Questa metrica dipende dal comportamento degli altri, quindi dal punto di vista soggettivo. Nota: per alcuni problemi un software può essere piuttosto utile e quindi considerato di alta qualità (Excel per i calcoli), ma non software di qualità per un problema diverso (Excel per riprodurre file MP3).

Il codice può (solitamente) essere misurato con metriche empiriche . Ma l'interpretazione non è "sì / no" per la qualità, o anche realmente su una scala da "0 a N". La metrica misura rispetto a uno standard. Quindi, le metriche possono trovare aree di interesse definite dallo standard, ma l'assenza di aree di interesse non è la prova che questo è un codice di qualità. Ad esempio, metriche utili: Compila? No - > Non di qualità Sì - > ???. Passa il test unitario? No? Può essere? (perché, è il codice di qualità del test unitario?), Sì - > ???.

Quindi, come la dimostrazione di incompletezza di Godel mostrata per gli assiomi della matematica (cioè, esistono affermazioni matematiche che non possono essere dimostrate vere o false per qualsiasi insieme finito di assiomi), non penso che potremmo mai rispondere in realtà " è questo codice di qualità? ' per ogni pezzo di codice. Intuitivamente, probabilmente c'è una mappatura tra le metriche del software per rispondere alla qualità e agli assiomi matematici per rispondere in modo dimostrabile vero o falso.

Un altro modo per rendere questo argomento, è quello di entrare nel linguaggio naturale. William Shakespeare, Lewis Carroll e Mark Twain erano tutti scrittori di successo e amati da molti per la qualità dei loro scritti. Eppure, quale standard di grammatica, vocabolario, stile o voce potremmo applicare che li classificherebbe costantemente più in alto rispetto ai dodicimari casuali? E, anche se potrebbe essere possibile creare una misura sintetica per quei tre, come giudicherà il Libro di Giovanni (KJV), J.R.R. Tolkien, Homer, Cervantes, ecc.? Quindi lanciare Burroughs, Faulkner, Hemingway, Sylvia Plath e così via. La metrica non funzionerà.

Lo misurerei controllando (e cercando le deviazioni) il loro processo.

Sarei alla ricerca di prove di un processo che garantisse il controllo del codice sorgente centrale, il sistema di compilazione centrale e un processo che garantisse il test del codice prima dell'integrazione nel ramo rilasciato.

Sarei anche alla ricerca di prove su come hanno modificato i loro processi in risposta a situazioni in cui i difetti hanno attraversato il loro processo di rilascio.

Se non sono in grado di superare questo livello di controllo, non puoi aspettarti che forniscano versioni affidabili e coerenti.

Se superano questo audit e migliorano continuamente il loro processo, è probabile che la loro coerenza di output migliori nel tempo.

Se ciò non risolve il problema, è probabile che abbiano un problema di architettura del codice che rende problematico estendere e testare il loro codice attuale, nel qual caso non ci sono buone opzioni.

Se stai cercando misurazioni completamente automatizzate, allora consiglio questi ragazzi: Software Improvement Group

È essenzialmente un aggregato di varie metriche che possono essere estratte automaticamente dal codice sorgente (come copertura del test unitario, dimensione della funzione, entanglement della classe, duplicazione, LOC, ecc.). Questi valori vengono quindi convertiti in una valutazione a 1-5 stelle.

Hannoancheunlibrodecentechedescriveinpraticatuttelelorometrichechevalelapenaleggere: "Costruire software gestibile" .