Definisco difetto come:
"something within the application design or code which prevents it functioning as per requirements."
Sto cercando idee sulle cause dei difetti, ad esempio il fattore umano, la mancanza di test, la mancanza di prototipazione e le possibili idee per mitigarli.
La causa principale dei difetti del software è l'interpretazione.
L'interpretazione del cliente di una funzionalità differisce dall'interpretazione del designer.
L'interpretazione del designer differisce dall'interpretazione del programmatore.
La maggior parte delle metodologie ha inventato modi per contrastare questo effetto. Ma alla fine, siamo solo umani e non siamo impeccabili. Inoltre, spesso c'è una pressione del tempo e la maggior parte della metodologia magica viene saltata spesso sotto pressione.
I test possono solo rilevare i problemi in anticipo. Ma anche i tester sono umani e non è possibile testare al 100%. Se vuoi rilasciare prima che l'universo finisca.
Ritengo che la causa principale dei difetti del software siano i programmatori.
Non dicendo che solo sia divertente, ma perché uno dei grandi problemi che ho osservato nel mio lavoro è la scarsa raccolta dei requisiti, unita a una scarsa comprensione del dominio del problema, che causa gravi difetti e problemi di usabilità nel progetto.
Parte di ciò deriva dal non voler imparare / comprendere la terminologia dell'utente finale, causando equivoci.
In parte ciò deriva dal parlare di tecnologia troppo presto nel processo a persone che non hanno la minima idea di cosa stai parlando o del perché è importante.
Il miglior esempio è stato quando ho sentito uno dei programmatori che cercava di capire per quanto tempo le domande / risposte sarebbero state nei personaggi ... Sapevo che stava cercando di capire quale campo dimensione usare nel database ma il dipartimento che lo richiedeva non aveva il motivo per cui era importante - o che gli spazi fossero contati. Per noi sembra ovvio, ma per loro è stata una vera rivelazione.
La causa principale dei difetti è gestione errata ;)
Scherzi a parte, uno sviluppatore che lavora in buone condizioni, che non è invitato a lavorare troppo, a ridurre la qualità, a strumenti adeguati, a condizioni di lavoro silenziose e così via produrrà meno bug di chi lavora sotto strong pressione.
Anche la gestione degli sviluppatori malintenzionati aiuta anche ad aumentare il numero di bug.
Gestione errata .
(disclaimer: dovrei assumere e gestire gli sviluppatori)
Non vedo alcuna causa primaria - ma una causa che non è stata menzionata è Accoppiamento non intenzionale con altro codice . Scrivere codice che ha effetti collaterali invisibili, sfondare i livelli di astrazione, fare supposizioni sui dati (le variabili no, le costanti non lo sono, e nessun input da parte di un utente è sicuro), muck con cose che non deve preoccupare stesso con, e così via.
La maggior parte delle pratiche di sviluppo che studio si riducono a ridurre N , perché la complessità di un programma è almeno O(N^2) e possibilmente O(k^N) . Definire N è lasciato come esercizio per il lettore, ma sto pensando a cose come la complessità ciclomatica qui. L'incapsulamento della logica e dei dati ha l'effetto di ridurre N compartimentalizzando il problema.
Spazio di comunicazione. Nella raccolta dei requisiti. In programma. Nel documento di progettazione. Nella specifica funzionale Nel codice (gap tra ciò che il programmatore vuole e ciò che dice al compilatore).
Etichetta sociale. È socialmente inaccettabile chiamare qualcuno incapace.
Correre nelle cose senza comprenderle appieno. Iniziare a scrivere codice senza comprendere pienamente i requisiti funzionali o l'architettura tecnica.
La programmazione dovrebbe essere quasi automatica, semplicemente annotando ciò che è evidente e già stato elaborato nella mente. In pratica, vedo molta agitazione nel codice per cercare di capire esattamente cosa dovrebbe fare il codice. Sono stato io stesso colpevole di questo me stesso molte volte.
Pressione programma è certamente una fonte strong.
Gli sviluppatori affrettati non impiegano il tempo necessario per specificare appieno i requisiti, o comprendere appieno l'intento alla base dei requisiti, o indagare a fondo sui supplenti per trovare la soluzione migliore, o pensare pienamente attraverso tutti i casi limite e le interazioni delle modifiche che sono realizzare o sviluppare una serie completa di casi di test, o eseguire completamente tutti i test unitari, eseguire un test di integrazione completo, o considerare completamente le dipendenze dalla piattaforma, o testare completamente l'installatore, o documentare completamente ciò che hanno fatto in modo che il prossimo lo sviluppatore può capire ....
Un'altra cosa che dovrebbe essere menzionata non è avere un test esterno. Quando lo sviluppatore scrive i test e li esegue, verifica solo la sua interpretazione e non il requisito reale. Mentre i test unitari scritti dagli sviluppatori sono utili per catturare alcuni bug, molti bug avranno superato questi test ma non saranno ciò che l'utente desidera o ha bisogno. Qualsiasi software non testato da qualcuno diverso dallo sviluppatore non è testato (e non intendo solo eseguire i test dello sviluppatore).
È perché l'ingegneria del software è intrinsecamente complessa. Il saggio "No Silver Bullet" parla di questo.
Ironia della sorte, molte delle altre risposte toccano argomenti che sono "accidentalmente complessi", nella lingua di quel saggio, mentre in realtà la maggior parte di ciò che gli sviluppatori di software fanno è "essenzialmente complesso", quindi è solo nella natura di che la creazione di software è difficile, il software avrà dei bug e il nostro compito è affrontarlo.
La mancata comprensione del software come una rete di macchine a stati, i principi alla base del loro funzionamento (stati, loro determinazione e transizioni) e le interazioni delle macchine a stati.
Scrittura di codice che fallisce silenziosamente rispetto al codice che riporta tutti gli errori.
Mancanza di controllo per cose che "non può accadere" o che difficilmente si verificheranno è grande. A volte il perfetto è il nemico del bene. Se non vale una gerarchia di eccezioni ben ponderata, un trattamento veloce e sporco è sempre meglio di niente. Sono un fan enorme di errori rapidi, di asserzioni e di affermazioni che hanno un impatto trascurabile sulle prestazioni nei build di rilascio. Anche in script one-off rapidi e sporchi in cui controllo tutti i dati di input, inserisco un po 'di gestione degli errori rapida / sporca, di solito solo con una funzione che è equivalente ad affermare ma che rimane sempre attiva. La mia regola generale è che, se non è probabile che si verifichi o pensi che non possa accadere, non ha bisogno di fallire con grazia con un messaggio di errore user-friendly, ma dovrebbe almeno fallire velocemente con un messaggio di errore che fornisce al programmatore alcuni suggerimenti su cosa è andato storto.
Modifica: una tattica utile correlata è quella di utilizzare gli asserti come uno strumento di debug principale e lasciarli lì dopo che la sessione di debug è terminata. Da quel momento in poi, il tuo codebase avrà alcuni controlli di integrità incorporati che rendono molto difficile il ripetersi di bug correlati. Questo è particolarmente utile per il codice che è difficile da rimuovere.
La causa principale dei difetti del software è la scrittura del codice.
Scrivi meno codice e avrai meno bug; -)
A un livello, la gestione. Ma non è solo il PHB. È la gestione del codice stesso, che può o non può essere un riflesso della gestione aziendale.
I partecipanti all'intero "ciclo di vita" devono essere pienamente investiti in qualità e realizzare un prodotto che non muoia . Il software stesso ha la promessa di non interrompere mai, data l'affidabilità dell'astrazione corretta. È solo una questione se i costruttori di software sono interessati ad avere quell'operazione perfetta.
Leggi altre domande sui tag bug programming-practices experience