Come fai a sapere se il software è buono o cattivo in base a metriche empiriche?

Attualmente mi viene chiesto di esaminare un progetto che ha terminato lo sviluppo del core cinque mesi fa, ma presenta ancora un alto livello di difetti. Ciò che si manifesta per ogni 10 difetti risolti, aumentiamo almeno 4 e in alcuni casi 8 difetti.

Credo che la pratica di codifica presso il venditore sia scarsa e vi è un accordo generale al riguardo. Tuttavia, mi chiedo se c'è un problema strutturale con il software? La densità dei difetti è una misura utile, ma più se il software di base è scritto male, tutto ciò che il fornitore sta facendo sta spostando il problema.

Nell'infrastruttura è più definito se qualcosa è costruito male, quali misure è possibile utilizzare per il software oltre ai difetti per LOC?

Il prodotto è in fase di correzione dei difetti da 4 mesi e non ha ancora risolto abbastanza difetti critici. Non stiamo iniettando nuove funzionalità, stiamo solo risolvendo problemi di regressione.

Ciò indica un problema di qualità dello sviluppo, che non è soddisfatto. Tuttavia, se il prodotto stesso è fondamentalmente difettoso, questo è un problema diverso. La preoccupazione è che la base di codice di base sia stata scritta male e abbia una documentazione limitata, tutto ciò che gli sviluppatori esterni stanno facendo sta spostando il problema da A a B. Una volta che i team di sviluppo interno prendono il controllo, sono preoccupato che dovranno sostanzialmente riscrivere il codice in rendilo funzionale.

Quindi, quando accetti un prodotto da una terza parte e ti viene chiesto di supportarlo, quali criteri di accettazione useresti per definire gli standard?

Oltre a convincere il nostro sviluppatore principale a fare una revisione tra pari del codice per versione, non sei sicuro di cos'altro si può fare?

Non

La qualità del software è davvero difficile da misurare oggettivamente. Abbastanza difficile da non avere una soluzione. Mi sto trattenendo in questa risposta per dilettarmi sulla domanda se ci può essere una soluzione, ma semplicemente sottolineare perché definire uno sarebbe davvero difficile.

Ragionamento per status quo

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

Ci sono progetti in cui i manager hanno deciso di applicare determinate metriche. A volte ha funzionato, a volte no. Non sono a conoscenza di correlazioni significative. Soprattutto i software di sistemi critici (ad esempio aeroplani, automobili, ecc.) Hanno molti requisiti metrici per "garantire" la qualità del SW - Non sono a conoscenza di studi che dimostrino che questi requisiti comportano effettivamente una qualità superiore e ho esperienze personali contrario.

Ragionamento da controspionaggio

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

Cosa significa giocare una metrica? È un gioco divertente per gli sviluppatori: assicurati che i valori della metrica 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 un codice stupido che si traduce in una non operazione su 100 righe e all'improvviso hai meno difetti per LOC. Soprattutto: in questo modo hai ridotto la qualità del software.

Le carenze degli strumenti vengono abusate, le definizioni vengono estese al massimo, vengono inventati modi completamente nuovi .. fondamentalmente, gli sviluppatori sono persone davvero intelligenti e se dovessi avere solo uno sviluppatore nel tuo team che si diverta a giocare con le metriche, le tue metriche saranno discutibili.

Questo non significa che le metriche siano sempre negative, ma l'atteggiamento del team nei confronti di queste metriche è cruciale. In particolare, ciò implica che non funzionerà bene per alcuna relazione di subappaltatore / fornitore di terze parti.

Ragionamento con targeting errato

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

C'è un divario tra ciò che misuri e ciò che credi che ti dirà. Questo divario è addirittura enorme.

Succede sempre in tutti i tipi di aziende che ci circondano. Hai mai visto decisioni basate su KPI (indicatori chiave di prestazione)? È solo lo stesso problema: vuoi che un'azienda faccia bene, ma misuri qualcos'altro.

Ragionamento per quantificabilità

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

Giudicare la qualità del software solo in base alle metriche e chiudere un occhio sulle parti di qualità che non è possibile quantificare non funzionerà sicuramente.

modificare:

Sommario

Vorrei sottolineare che quanto sopra si basa sul giudicare obiettivamente se il software è buono o cattivo in base alle metriche. Ciò significa che non sta dicendo nulla su se e quando applicare le metriche.

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

Misuri il software A e le metriche risultano davvero pessime. Quindi puoi essere certo che la qualità del codice è scarsa. Misuri il software B e le metriche sono ok, quindi non hai idea della qualità del codice. Non farti ingannare dal pensiero "metrica buona = codice buona" quando in realtà è "buona codifica => metrica buona".

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

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

Più specificamente, esegui uno strumento di analisi della complessità sulla base di codice e avrai un'idea del fatto che il codice sia buono o cattivo.

Ad esempio, è possibile eseguire il monitoraggio del codice sorgente .

Ciò che questo ti dirà è quanto sia complesso il codice. Posso dirti che ogni sistema problematico che ho sperimentato ha avuto numeri cattivi. Complessità su metodi da 10 a 100 ben oltre limiti accettabili. Numeri terribili Terribile complessità, nidificazione, profondità, ecc. Ciò comporterà molti problemi, un tasso di difetti elevato e costante, modifiche difficili da apportare, senza interrompere qualcos'altro, ecc.

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

La trama dovrebbe assomigliare a questa:

Difetti nel tempo

Se rimangono costanti o aumentano, il software non è buono. Sono solo 4 mesi, quindi gli darei qualche mese in più di un anno. Dopo 6 mesi o un anno, se hai avuto un flusso costante di difetti, allora è di cattiva qualità. La tua squadra ha sviluppato un'altra palla di fango .

Test successivi. Li hai? Se non allora meno qualità, più bug, più zangola. Se li hai, le metriche come la copertura del codice sono buone per avere un'idea di quanto codice viene coperto, ma non misurerà la qualità . Ho visto ottimi numeri di copertura del codice ma i test effettivi sono stati una schifezza. 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 fare dei test e devono essere bravi. Le metriche di copertura del codice non sono di per sé un indicatore di qualità.

Revisioni del codice, le stai eseguendo? Altrimenti, meno qualità. Ciò è particolarmente importante con gli sviluppatori junior. Se sei agile, aggiungi semplicemente un'attività di revisione del codice alla tua storia chiamata "revisione del codice". Se la direzione vuole tenere traccia dei numeri, avrai bisogno di uno strumento che tenga traccia delle recensioni come Crucible . Penso che i numeri o le metriche di revisione del codice non siano così importanti qui oltre al fatto che dovrebbero essere parte del tuo processo. Non tutti i check-in richiedono una revisione. Tuttavia, le recensioni possono aiutare a garantire che le persone non reinventino la ruota o stiano scrivendo codice che altri non possono capire e / o mantenere.

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

• Scarse strutture di dati. Tutto è una stringa o XML viene passato ovunque e analizzato ovunque, oggetti divini o strutture di dati genericamente o inutilmente complesse, nessun modello di dominio.
• Mancanza di organizzazione o struttura, qualsiasi progetto non banale dovrebbe avere una divisione o stratificazione che separa la logica. Dai un'occhiata qui ... Se non vedi questo tipo di organizzazione o separazione (mescolanza di logica ovunque), il sistema sarà più difficile da mantenere e capire.
• Oltre le astrazioni. A volte è vero il contrario, il sistema è troppo astratto. Se tutto è un'interfaccia e una classe astratta, o devi navigare attraverso una moltitudine di classi di tipo "wrapper" di classe, la qualità sarà cattiva perché i nuovi sviluppatori non saranno in grado di navigare attraverso l'oggetto gonfio.
• Codice difficile da capire. Se sei uno sviluppatore esperto e stai cercando un codice così difficile da capire, avrà problemi di qualità. La mia metrica personale è che se sto guardando il codice ed è difficile seguirlo o mi fa sembrare stupido, o mi sento come se stessi sprecando un sacco di cicli cerebrali per capire la logica, allora è un cattivo codice. Se gli sviluppatori esperti hanno difficoltà a seguire, immagina come sarà per gli sviluppatori più recenti. Introdurranno problemi.

Il mio consiglio sarebbe di eseguire un'analisi della complessità sul codice. Non condividere i risultati, invece segui i risultati facendo alcune indagini indipendenti (guarda il codice) e fai una determinazione dello stato generale della base di codice. Da questo, forma un piano d'azione e prova a rimediare ad 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, esiste un'impostazione per trattare gli avvisi del compilatore come errori. Ora alcune persone non capiscono gli avvisi e, per ottenere il codice compilato, useranno semplici trucchi (come "avviso di disabilitazione della proprietà" o l'aggiunta di una "nuova parola chiave" a una funzione / proprietà che nasconde un membro non virtuale di una base classe).

Se hai accesso al codice sorgente, puoi eseguire l'analisi del codice statico. Per i progetti .Net, è possibile utilizzare ad es. FxCop o ReSharper InspectCode. Se utilizzati correttamente dal team di sviluppo, gli strumenti contribuiranno a migliorare la qualità. Ma, naturalmente, sono possibili alcune "correzioni" per la rimozione degli avvisi senza capirli.

Potresti guardare test automatici / UnitTest: quanto è buona la copertura del codice? Ma la copertura da sola non ti dirà se i test controllano effettivamente il codice o se lo hanno eseguito una volta sola.

La ricerca dell'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 considerare oltre a raccogliere una metrica come l'iniezione di difetti è capire l'origine dei difetti. Spesso è correlato alle specifiche.

Fondamentalmente, è un errore nelle specifiche, un'ambiguità nella specifica, lasciato agli impianti per decidere o è un bug nell'implementazione.

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

In fondo, non c'è modo di 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 si trattasse di una libreria o di un'applicazione, di quanto sia grande la base di codice, di quanto sia grande il dominio problematico e di quale sia la gravità dei difetti. Ad esempio, non gestire uno dei 123 formati di input potrebbe essere un difetto insignificante o un blocco dello spettacolo, a seconda dell'importanza del formato non gestito correttamente. E meglio di niente è uno standard elevato.

Presuppongo che faccio questa domanda: esiste una differenza tra codice e software. Definisco il software come ciò che un cliente / utente utilizza per risolvere un problema, mentre il codice è il materiale da costruzione del software.

Il software può essere misurato solo soggettivamente. 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 soggettivamente. Nota: per alcuni problemi un software può essere abbastanza utile e quindi considerato di alta qualità (Excel per i calcoli), ma non software di qualità per un problema diverso (Excel per la riproduzione di file MP3).

Il codice può (di solito) essere misurato con metriche empiriche . Ma l'interpretazione non è "sì / no" per qualità, o addirittura su una scala da "0 a N". Le metriche misurano rispetto a uno standard. Pertanto, le metriche possono trovare aree di preoccupazione definite dalla norma, ma l'assenza di aree di preoccupazione non è la prova che si tratta di un codice di qualità. Ad esempio, metriche utili: si compila? No -> Non qualità. Sì -> ???. Supera il test unitario? No? Può essere? (perché, è il codice qualità unit test?), 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 nessun insieme finito di assiomi), non credo che potremmo mai realmente rispondere "è questa qualità codice?' per ogni parte di codice. Intuitivamente, c'è probabilmente una mappatura tra metriche del software per rispondere alla qualità e assiomi matematici per rispondere in modo dimostrabile vero o falso.

Un altro modo di fare questo argomento è 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 alla terza elementare casuale? E, mentre potrebbe essere possibile creare una misura sintetica per quei tre, come giudicherebbe il Libro di Giovanni (KJV), JRR Tolkien, Homer, Cervantes, ecc.? Quindi aggiungi Burroughs, Faulkner, Hemingway, Sylvia Plath e così via. La metrica non funzionerà.

Misurerei questo verificando (e cercando deviazioni) nel loro processo.

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

Vorrei anche cercare prove di come hanno modificato i loro processi in risposta a situazioni in cui i difetti sono passati attraverso il loro processo di rilascio.

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

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

Se ciò non lo risolve, è probabile che abbiano un problema di architettura del codice che renda problematica l'estensione e il test della loro base di codice attuale, nel qual caso non ci sono buone opzioni.

Se stai cercando misure completamente automatizzate, allora consiglio a 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 di classe, duplicazione, LOC, ecc.). Tali valori vengono quindi convertiti in 1-5 stelle.

Hanno anche un libro decente che descrive in pratica tutte le loro metriche che vale la pena leggere: "Costruire software gestibile" .