Formalizzare gli errori dei programmatori

Quello che stai cercando è una tassonomia di bug del software. Ecco alcune di queste tassonomie:

• link
• link
• link

Ecco anche un documento di tesi di qualcuno che ha esaminato 26 diverse tassonomie di bug.

Probabilmente scoprirai che ogni tassonomia è leggermente diversa, con diverse categorie, diversi livelli di dettaglio e persino concetti di base completamente diversi.

Non mi preoccuperei troppo di quali categorie scegliere esattamente, o quale categoria assegnare anche ai singoli bug. Sembra un inutile esercizio inutile mirare alla categorizzazione perfetta di qualcosa di vario come bug del software.

Dai un'occhiata a Brain Hayes " Debugging Myself . Non sono sicuro che abbia iniziato con le categorie di errore, o semplicemente le ha determinate con il passare del tempo.

Penso che questa sia un'area intrinsecamente difficile. Cosa classifichi come errore? Personalmente non classificherei un errore di battitura come errore, ma se stai facendo un processo software personale, sono abbastanza sicuro che classifichi le parole chiave errate come un errore.

Direi che, se vuoi capire i tuoi errori di programmazione, dovresti pensare a ciò che conta per te. Personalmente penso ai miei errori di programmazione nelle seguenti categorie:

1. Errori di ufficio . Esempi sono errori di battitura, chiamate a funzioni / metodi sbagliati, l'ordine degli argomenti è sbagliato ecc. In genere compilatori e controllori di tipi intercettano tali errori, oppure esegue un semplice esercizio del codice.

2. Malintesi del programma . Potrei non avere una piena comprensione del programma (o dei suoi componenti, classi, librerie o qualsiasi altra cosa), o fraintenderli, e ho scritto il codice sbagliato che non si adattava. Di solito questi errori vengono catturati dai primi cicli di test di routine.

3. Malintesi dei requisiti . Dovevo fare X ma ho fatto Y. O non ho capito completamente i requisiti o li ho fraintesi. Questi vengono catturati dai primi cicli di test dell'utente.

4. Difetti logici . Questi sono i biggies. Supponendo di aver capito tutto correttamente, ho comunque finito per scrivere il codice sbagliato. Questi sono non semplicemente errori "umani" . Ero pigro, non pensavo attentamente alle cose, usavo algoritmi o strutture dati sbagliati che non andavano bene, il problema era troppo difficile e complicato e non avevo messo abbastanza impegno per farlo bene, o forse non lo ero essere all'altezza del compito Questi di solito non vengono catturati dai test di routine e vanno in distribuzione. Grande problema. Ogni volta che ottengo uno di questi, penso a lungo e duramente su come evitare una cosa del genere in futuro.

5. Problemi di progettazione . Usato la struttura dei dati sbagliata, le interfacce sbagliate, la struttura del programma sbagliata o qualsiasi altra cosa. Queste cose non influenzano il comportamento del programma, ma influenzano lo sviluppo futuro. Esse si traducono in un sistema fragile che non può essere esteso o modificato facilmente, causare un numero sempre maggiore di bug dei tipi precedenti per un periodo di tempo, o semplicemente risultare in una struttura di cui non sono orgoglioso. Per risolvere questi problemi è necessaria una certa quantità di refactoring doloroso e noioso. Ogni volta che ne ottengo uno, imparo qualcosa di nuovo e profondo sulla natura della programmazione.

Il processo di software personale sottolinea molte di queste cose. Migliorare la qualità e la stima tenendo registri del passato / presente. Ti consiglio di consultare moduli di esempio per le idee.

Nessuna delle risposte precedenti riguarda cause di bug del software in termini di errori umani da parte del codificatore. Ci sono molte ricerche sugli errori umani nelle aree di sicurezza degli operatori umani critici, come gli errori del pilota aeronautico da parte della FAA e dell'NTSB. C'è anche una ricerca sulla memoria umana e sulla fallibilità percettiva che potrebbe essere applicabile.

Il test delle unità è come l'avviso di stallo che si spegne dopo che il pilota si è già avvicinato a un regime di volo pericoloso. Uno studio personale su come non creare, o su come minimizzare, il codice che produce risultati per i test unitari da trovare e fallire sembra al minimo interessante.

L'ho fatto in misura molto limitata:

I had a production application with a lot of live users. The system had an in-built error logger. During critical errors, it would send detailed email reports.

Dal momento che tutto è stato registrato, è stato possibile vedere le tendenze e consentito agli sviluppatori di concentrarsi su aree diverse (a volte su cui normalmente non ci concentreremo).

SO

Un approccio più automatizzato sarebbe meglio.

Forse potresti creare un'applicazione in grado di registrare e analizzare gli errori del compilatore e incrociarli con i registri di controllo del sorgente insieme ai rapporti di errore automatici dalle applicazioni live?