Quale ritieni sia la causa principale dei difetti del software (e come minimizzarli) [chiuso]

Definisco il difetto come:

"qualcosa all'interno del design o del codice dell'applicazione che ne impedisce il funzionamento secondo i requisiti."

Sto cercando idee sulle cause dei difetti, ad esempio il fattore umano, la mancanza di test, la mancanza di prototipazione e 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.

Molte metodologie hanno 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 magia della metodologia viene spesso saltata mentre è sotto pressione.

I test possono rilevare solo i problemi in anticipo. Ma anche i tester sono umani ed è impossibile testarli al 100%. Se vuoi rilasciare prima della fine dell'universo.

Considero i programmatori la prima causa di difetti del software.

Non per dirlo solo per essere divertente, ma perché uno dei maggiori problemi che ho riscontrato nel mio lavoro è la scarsa raccolta di requisiti, unita alla scarsa comprensione del dominio del problema, causando gravi difetti e problemi di usabilità nel progetto.

Parte di ciò deriva dal non voler apprendere / comprendere la terminologia dell'utente finale, causando incomprensioni.

Parte di ciò deriva dal parlare della tecnologia troppo presto nel processo a persone che non hanno idea di cosa tu stia parlando o perché sia ​​importante.

Il miglior esempio di ciò è stato quando ho sentito per caso uno dei programmatori che cercava di capire per quanto tempo sarebbero rimaste le domande / risposte in caratteri ... Sapevo che stava cercando di capire quale campo di dimensioni usare nel database, ma il il dipartimento che richiedeva questo non aveva il più nebuloso motivo per cui ciò contava o che gli spazi contano. Per noi questo sembra ovvio, ma per loro è stata una vera rivelazione.

La causa principale dei difetti è una cattiva gestione ;)

Scherzi a parte, uno sviluppatore che lavora in buone condizioni, a cui non viene chiesto di lavorare troppo, di tagliare la qualità, avere strumenti adeguati, condizioni di lavoro silenziose e così via produrrà meno bug rispetto a chi lavora sotto pressione.

Anche il management che assume cattivi sviluppatori aiuta anche ad aumentare il numero di bug.

Cattiva gestione .

(dichiarazione di non responsabilità: dovrei assumere e gestire sviluppatori)

Non vedo alcuna causa primaria, ma una causa che non è stata menzionata è l' accoppiamento involontario con altro codice . Scrivere codice che ha effetti collaterali invisibili, supera i livelli di astrazione, fa ipotesi sui dati (le variabili non lo sono, le costanti non lo sono e nessun input da parte di un utente è sicuro), fa a pezzi cose che non devono preoccuparsi stesso con e così via.

La maggior parte delle pratiche di sviluppo che studio si riducono alla riduzione N , perché la complessità di un programma è almeno O(N^2)e forse O(k^N). La definizione Nè lasciata come esercizio per il lettore, ma sto pensando a cose come la complessità ciclomatica qui. La logica e i dati incapsulati hanno l'effetto di ridurre N scompartendo il problema.

L'incapacità di pensare a tutto.

Essere incompleto

Gap di comunicazione. Nella raccolta dei requisiti. In programma. Nel documento di progettazione. Nelle specifiche funzionali. Nel codice (divario tra ciò che il programmatore vuole e ciò che dice al compilatore).

Etichetta sociale. È socialmente inaccettabile chiamare qualcuno incapace.

Correre in cose senza comprenderle appieno. Iniziare a scrivere codice senza comprendere appieno i requisiti funzionali o l'architettura tecnica.

La programmazione dovrebbe essere quasi automatica, semplicemente scrivendo ciò che è evidente ed è già stato elaborato nella mente. In pratica, vedo un sacco di errori nel codice per cercare di capire esattamente cosa dovrebbe fare il codice. Me ne sono reso colpevole molte volte.

Errare humanum est

Pianificazione La pressione è certamente una fonte forte.

Gli sviluppatori affrettati non si prendono il tempo per specificare completamente i requisiti, o comprendere appieno l'intento alla base dei requisiti, o indagare a fondo sui supplenti per trovare la soluzione migliore, o riflettere a fondo su tutti i casi limite e le interazioni dei cambiamenti che stanno apportando, o sviluppare un set completo di casi di test, oppure eseguire completamente tutti i test unitari, oppure eseguire un test di integrazione completo, oppure considerare completamente le dipendenze della piattaforma o testare completamente l'installatore o documentare completamente ciò che hanno fatto in modo che lo sviluppatore successivo possa 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 effettivo. Mentre i test unitari scritti dagli sviluppatori sono utili per rilevare alcuni bug, la maggior parte dei bug ha superato questi test ma non è ciò che l'utente desidera o necessita. 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" ne discute.

Ironia della sorte, molte delle altre risposte qui toccano argomenti che sono "casualmente complessi", nel linguaggio di quel saggio, mentre in realtà la maggior parte di ciò che fanno gli sviluppatori di software è "essenzialmente complesso", quindi è proprio nella natura di ciò che la creazione il software è difficile, il software avrà dei bug e il nostro compito è affrontarlo.

L'incapacità di comprendere il software come una rete di macchine a stati, i principi alla base del loro funzionamento (stati, determinazione e transizioni) e le interazioni delle macchine a stati.

Scrivere codice che fallisce silenziosamente vs. codice che riporta tutti gli errori.

La mancanza di controllo per cose che "non possono accadere" o è improbabile che accada è una grande cosa. A volte il perfetto è nemico del bene. Se non vale una gerarchia di eccezioni ben ponderata, una gestione rapida e sporca è sempre meglio di niente. Sono un grandefan di fallire velocemente, di affermazioni e di lasciare affermazioni che hanno un impatto trascurabile sulle prestazioni nelle build di rilascio. Anche negli script una tantum rapidi e sporchi in cui controllo tutti i dati di input, inserisco un po 'di gestione degli errori rapidi / sporchi, di solito solo con una funzione che è equivalente ad affermare ma rimane sempre attiva. La mia regola empirica è 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 intuitivo, ma almeno dovrebbe 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 dei principali strumenti di debug e lasciarli lì al termine della sessione di debug. Da quel momento in poi, la tua base di codice avrà alcuni controlli di integrità che rendono molto difficile il ripetersi di bug correlati. Ciò è particolarmente utile per il codice difficile da unittest.

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 meno essere un riflesso della gestione aziendale.

I partecipanti all'intero "ciclo di vita" devono essere completamente investiti nella qualità e nella realizzazione di un prodotto che non muore . Il software stesso ha la promessa di non rompersi mai, data la corretta affidabilità di astrazione. È solo una questione se i costruttori di software sono interessati ad avere quell'operazione perfetta.