Ricerca sui difetti del software [chiuso]

L'unico documento interessante che ho trovato è stato Confronto tra bug osservato e tassi di produttività per Java e C ++ (richiesta iscrizione ACM), pubblicata nel 1999. L'autore ha utilizzato un processo software personale modificato per raccogliere informazioni sulla produttività e sui difetti. L'autore ha scoperto che un programma C ++ conteneva 2-3 volte più difetti di un programma Java, il C ++ ha generato il 15-30% in più di difetti per riga e Java era il 30-200% più produttivo nelle righe di codice prodotte nel tempo. Poiché è stato utilizzato un solo programmatore e questo individuo era esperto in C ++, ma stava solo imparando Java, non è definitivo e un programmatore Java esperto sarebbe più esperto. Tuttavia, questo studio è stato notevole perché fornisce una metodologia per misurare la produttività di un linguaggio di programmazione.

Vorrei segnalare alcuni possibili problemi ...

Le linee di codice sono una misurazione tremolante, nel migliore dei casi. È facile contare con vari strumenti e questi strumenti hanno spesso regole configurabili in modo da ottenere i conteggi ottimali per lo stile di codifica della tua organizzazione. Comunque, una linea di Python non è la stessa di una linea di C - puoi fare molto di più in una linea di Python che una linea di C.

La metrica che discutono in Making Software, defects / SLOC, si chiama densità dei difetti. È una metrica abbastanza comune, ma poiché è basata su SLOC, soffre degli stessi problemi di qualsiasi metrica basata su SLOC. È necessario disporre di un metodo di conteggio standardizzato e utilizzarlo in modo coerente. Inoltre, non è possibile confrontare facilmente la densità dei difetti tra i linguaggi di programmazione con qualsiasi valore.

Inoltre, il semplice confronto dei linguaggi di programmazione non è necessariamente un confronto equo. È inoltre necessario confrontare strumenti e risorse disponibili. Ad esempio, è possibile utilizzare l'analisi statica e le revisioni del codice per ridurre i difetti. Lingue diverse hanno un supporto variabile per analisi statiche, test di unità e potresti non avere accesso a persone abbastanza esperte nella lingua per condurre una revisione del codice.

In definitiva, penso che parlare di verbosità contro difetti sia la cosa sbagliata da fare. È meglio esaminare tecniche e processi per ridurre i difetti a un livello accettabile per il tuo prodotto. Ciò include la scelta del linguaggio di programmazione, in termini di produttività, dati il tuo team e gli strumenti di supporto.

Ci sono cose interessanti là fuori. Questi sono i miei preferiti, in quanto includono dati empirici e non sempre corrispondono a Accepted Dogma sui bug:

• Andy Ozment's Latte o vino - In contraddizione con la gestione Dogma che ogni pezzo di software ha un numero infinito di bug (ad es. bugginess frattale).
• Il famoso ricercatore di sicurezza di Cambridge, Ross Anderson, ha scritto Open and I sistemi chiusi sono equivalenti
• Eric Rescorla, La ricerca di buchi di sicurezza è una buona idea?
• Geoffrey Phipps, Confronto tra bug osservato e tassi di produttività per Java e C ++
• David Atkins, Thomas Ball, Todd Graves, Audris Mockus, Utilizzo Versione Controllo dei dati per valutare l'impatto degli strumenti software
• Todd Graves, Alan Karr, J.S. Marron, Harvey Siy, Errore di previsione Incidenza utilizzando la cronologia delle modifiche del software

It would be easy to infer from this that choosing a less verbose language (a dynamic language?) will result in less lines of code and thus less defects. But the research in "Making Software" did not discuss the effect of language choice on defects, or on the class of defects. For example, perhaps a java program can be rewritten in clojure (or scala, or groovy, or...) resulting in more than 10x LOC savings. And you might infer 10x less defects because of that.

no no no :-) Non c'è modo di inferire dal fatto che più righe di codice C sono correlate con più difetti che un linguaggio più espressivo avrà meno difetti per lo stesso problema . Il primo è un gioco da ragazzi, per un dato sviluppatore, dato il langauge, più linee di codice avranno più bug.

But is it possible that the concise language, while less verbose, is more prone to programmer errors (relative to the more verbose language)? Or, that defects written in the less verbose language are 10x harder to find and fix? The research in "Making Software" was a fine start, but it left me wanting more. Is there anything published on this topic?

È sicuramente possibile . Forse è meno leggibile? Forse ha funzioni e operatori difficili da ricordare e facili da confondere? Prendi C e rinomina printf () in p (), sin () in s (), cos in c (). Codice più breve, giusto?

Studiare questo genere di cose è estremamente complicato. Pensa a tutte le variabili che devi controllare. Esperienza, dimensioni del progetto, area di applicazione, lanuage, ambiente, gestione. Forse funziona per l'analisi numerica ma non funziona per lo sviluppo web? Forse puoi mostrarlo agli studenti ma non agli sviluppatori senior? Forse è vero per uno sviluppatore seduto in uno spazio aperto ma non in un ufficio? Forse è vero per gli americani ma non per il giapponese? Forse è vero per l'open source ma non per gli sviluppatori commerciali?

Esistono numerosi studi sulla produttività dei linguaggi di programmazione, ad esempio:

Haskell vs. Ada vs. C ++ vs. awk vs .... un esperimento sulla produttività del prototipo del software

Ai tempi in cui le persone spingevano per Ada c'erano alcuni studi che mostravano quanto fosse migliore in termini di tasso di difetti e produttività. Ada è un esempio di linguaggio progettato per l'obiettivo di eliminare i difetti.

Questa domanda mi ricorda questo post del blog Hume, Causation & Scienza

Il mio suggerimento è scoprire cosa funziona per tu dati i tuoi punti di forza e l'area di applicazione. Non cercare studi per dirti cosa fare, uno studio può darti delle buone idee, ma devi capire i limiti di questi studi.

Ecco un'osservazione personale: puoi allenarti ad abbassare la frequenza dei tuoi difetti. Ho scoperto che fare gare su TopCoder in cui ottieni un riscontro immediato per i difetti ti allenerà abbastanza rapidamente per eliminare alcuni difetti comuni e pensare ai casi d'angolo (che sono i punti in cui si trovano molti difetti). Questo genere di cose farà uno studio interessante ...

In termini di previsione del tasso di difetti ho letto un articolo indietro sulla correlazione tra risultati e difetti dell'analisi statica: L'efficacia degli strumenti di analisi statica automatica per il rilevamento dei guasti e Previsione del refactoring (tl; dr non esattamente correlato ma il codice cattivo tende ad avere più problemi sebbene i difetti non possano essere identificati).

Non ho letto Making Software, quindi non posso commentare le conclusioni che hanno tratto nel loro libro. Tracciare gli errori o le righe di codice può essere fuorviante al meglio, perché le righe di codice non implicano necessariamente il grado di complessità della logica contenuta all'interno. Le linee di codice sono spesso più utili quando si determina il tempo rispetto allo sforzo / al costo, come uno strumento di gestione che misura approssimativamente la capacità di lavoro di una squadra, e anche in questo caso può essere difettoso.

Quando utilizzi le metriche per misurare la qualità del codice e la probabilità di errore, ho trovato quanto segue molto utile:

1. Copertura del codice
2. Lunghezza del percorso di istruzioni
3. Cyclomatic Complexity

L'uso di un buon profiler può essere di grande aiuto nel fornire misurazioni utili per aiutare non solo ottimizzare il codice, ma per avere un'idea della probabilità che un numero significativo di bug sia intrinseco al sistema. FWIW, trovo che il profilo ANT di Redgate sia uno dei migliori profiler .NET.

Ora torna alla tua domanda. Le metriche del software sono state discusse almeno dai primi anni '70 per quanto ne so, sebbene se dovessi indovinare direi che probabilmente l'argomento era interessante anche prima.

...is it possible that the concise language, while less verbose, is more prone to programmer errors (relative to the more verbose language)? Or, that defects written in the less verbose language are 10x harder to find and fix?

Direi che non solo è del tutto possibile, è anche molto probabile, sia per la brevità del linguaggio, sia per la sua complessità intrinseca. Ad esempio, Assembler è tanto breve quanto un linguaggio può essere sintatticamente, e richiede un'attenzione molto attenta ai dettagli al fine di ridurre al minimo i bug, eppure, essendo più prolisso, si hanno molte più opportunità per confermare lo stato impostando i breakpoint praticamente in ogni stato modificare. Detto questo, di solito è più difficile individuare i problemi con gli occhi da solo nell'assemblatore rispetto a un linguaggio di livello superiore con codice ben calcolato.

Se invece si riduce la verbosità, si intende un linguaggio di alto livello che gestisce un numero di operazioni comuni attraverso un singolo comando, quindi è necessario assumere che il comando come una scorciatoia sia esso stesso senza errori e che lo scopo a cui hai applicato il comando è anche senza errori. La sintassi del comando less verbose può anche avere l'effetto di introdurre un elemento di offuscamento nel codice a seconda del modo in cui viene utilizzata la sintassi.

Is there anything published on this topic?

L'articolo di Wikipedia su Metriche del software ha alcuni link ad alcuni documenti, e così fa anche ciascuno dei parametri che elencato in precedenza. Riguardo al modo in cui la peer review ha riguardato tutte queste informazioni, non ne sono del tutto sicuro, ma sì, sembra che ci siano molte informazioni pubblicate là fuori su questo argomento, che è molto probabilmente la carne e le patate di molte tesi avanzate di CompSci . ;)

Modifica: ho riorganizzato la mia risposta perché voglio sottolineare un punto diverso.

A volte la verbosità può aiutare a rendere i difetti più facili da individuare e correggere. Considera la formula quadratica (radice positiva solo per motivi di semplicità):

float quad(float a, float b, float c)
{
   return (-b + sqrt(b*b - 4*a*c)) / (2*a);
}

E questa implementazione equivalente:

float quad(float a, float b, float c)
{
    float discriminant = b*b - 4*a*c;
    float numerator = -b + sqrt(discriminant);
    float denominator = 2*a;
    float root = numerator/denominator;
    return root;
}

Quest'ultimo, anche se un po 'estremo, è uno stile comune che semplifica l'introduzione nel debugger e riduce anche il rischio di parentesi errata, un errore comune. Le espressioni composte, sebbene ovviamente una caratteristica comune nei linguaggi di alto livello, non sono onnipresenti e spesso rendono gli errori più difficili da trovare.

È perfettamente concepibile che una libreria matematica scritta da qualcuno che preferisce lo stile precedente potrebbe essere 3KLOC, e una libreria matematica scritta da qualcuno che preferisce quest'ultimo potrebbe essere 10KLOC - e che quest'ultimo ha meno difetti.

The research in "Making Software" was a fine start, but it left me wanting more. Is there anything published on this topic?

Non penso che la LOC sia una buona stima del numero di bug in molte (la maggior parte) delle lingue, anche se capita di essere una misura efficace in C. I vincoli spesso aumentano la LOC riducendo i difetti. Esistono molti tipi di vincoli, tra cui molti che sono funzionalità linguistiche non disponibili in C:

• Convenzioni di denominazione in inglese corretto
• Test di unità / TDD
• Asserzioni di runtime
• tipo di sicurezza
• Pre / Post-condizioni
• invarianti
• Unità di misura (probabilmente un tipo di sicurezza del tipo)

Ma secondo questo studio , TDD può quasi raddoppiare LOC ma ridurre i bug. (Non credo che questo sia il risultato di TDD tanto quanto risultato dei test unitari, ma questa è un'altra storia.)

No, il TDD non è una funzione linguistica, e no, non penso che il codice di test unitario debba contare direttamente su LOC, ma è molto un'altra forma di vincolo e mostra che i vincoli, anche se aumentano il codice, funzionano per ridurre i bug.

Inoltre, se ad esempio tutte le lingue supportassero unità di misura eccetto una lingua, a parità di tutte le altre, quella lingua sarebbe più concisa, e i programmi in quella lingua avrebbero più bug, tra cui ones che possono distruggere astronavi .

It would be easy to infer from this that choosing a less verbose language (a dynamic language?) will result in less lines of code and thus less defects.

Facile e il più vicino possibile da correggere con quel set di dati. Linee di codice sono dove gli errori devono essere. Meno codice contiene meno errori di porto.

But the research in "Making Software" did not discuss the effect of language choice on defects, or on the class of defects.

In realtà. Lo ha fatto. Ti ha dato i fatti. Meno righe di codice significano meno errori.

For example, perhaps a java program can be rewritten in clojure (or scala, or groovy, or...) resulting in more than 10x LOC savings. And you might infer 10x less defects because of that.

Questo non dovrebbe essere corretto. Lo hanno detto correlato. Non hanno detto che la relazione è lineare.

Ci sono errori all'esterno del codice. Errori di specifica Errori di test Ci sono difetti non di codice e difetti di codice.

But is it possible that the concise language, while less verbose, is more prone to programmer errors (relative to the more verbose language)?

No. Le lingue concise hanno meno errori. È davvero così semplice.

Il problema è che le lingue super-concise possono essere difficili da scrivere. Quindi il costo sale anche se il numero di errori diminuisce. La manutenzione può essere molto difficile. Lingue come APL o I sono spesso lingue di scrittura una volta. Il codice è così denso che è difficile fare un cambiamento; è spesso più facile ricominciare dall'inizio e scrivere tutti i nuovi programmi.

L'altro problema è che gli errori non di codice iniziano a dominare dopo un po '. Un linguaggio buono e conciso, in particolare un DSL che è davvero adatto al dominio del problema, rivela che esistono numerose altre fonti di errori.

Per evitare un sacco di discussioni sfumate (e inutili)

• Lo studio citato è ovviamente incompleto.

• Se hai una spiegazione più sfumata, condividi il tuo studio e pubblica i tuoi risultati in modo che possiamo discuterne.

• Concentrati sulla domanda, se possibile. Se vuoi introdurre nuove prove, apri una nuova domanda o commenta la domanda stessa per introdurre nuove prove.