Come essere un programmatore zero bug? [chiuso]


168

Il mio capo mi ha sempre detto che un buon programmatore dovrebbe essere in grado di garantire che il codice che modifica sia affidabile, corretto e completamente verificato da solo; che dovresti comprendere completamente tutti i risultati e gli impatti che le tue modifiche causeranno. Ho fatto del mio meglio per essere questo tipo di programmatore, testando ancora e ancora, ma i bug sono ancora lì.

Come posso essere un programmatore zero-bug e sapere cosa causerà e influenzerà ogni carattere del mio codice?


Nessuno in realtà crea il codice perfetto la prima volta, tranne me. Ma c'è solo uno di me. - Tech Talk: Linus Torvalds su git, Google, 15 agosto 2007 izquotes.com/quote/273558
JensG


Non esiste una programmazione a 0 bug. Leggi il matematico Godel per capire il perché.
Michael Martinez,

Risposte:


365

Non codificare affatto.

Questo è l'unico modo in cui puoi essere un programmatore zero bug.

I bug sono inevitabili perché i programmatori sono umani, tutto ciò che possiamo fare è fare del nostro meglio per prevenirli, reagire rapidamente quando si verifica un bug, imparare dai nostri errori e rimanere aggiornati.


73
+1 Follow-up: Oppure potresti diventare un architetto non codificante (torre d'avorio) e comunque essere pagato molto! Questo è il migliore.
Martin Wickman,

26
Errare è umano, riparare divini i tuoi insetti.
Ward Muylaert,

11
Avevo un collega che era favorito dal capo perché aveva costantemente un piccolo conteggio dei bug. Come l'ha fatto? Semplice, ha assegnato i bug che non voleva a qualcun altro e ha sempre assunto le funzionalità più semplici / più piccole.
entro il

46
Non so chi l'abbia detto per primo, ma "Se il debug è il processo di rimozione dei bug, allora la programmazione deve essere il processo per inserirli".
Bruce Alderman,

8
Ancora meglio: diventa un capo e fai sentire i tuoi fratelli infelici senza doversi assumere la responsabilità di nulla.
biziclop,

124

Zero bug è impossibile per un programma non banale.

È possibile avvicinarsi molto, ma la produttività ne risente. E vale la pena solo per alcuni software ad alto rischio. Il software Space Shuttle viene in mente. Ma la loro produttività è dell'ordine di poche righe al giorno. Dubito che il tuo capo lo voglia.

Questo software è privo di bug. È perfetto, perfetto come gli esseri umani hanno raggiunto. Considera queste statistiche: le ultime tre versioni del programma - ognuna lunga 420.000 righe - avevano un solo errore ciascuna. Le ultime 11 versioni di questo software hanno totalizzato 17 errori.

Effettua l'aggiornamento del software per consentire allo shuttle di navigare con i satelliti di posizionamento globale, una modifica che coinvolge solo l'1,5% del programma o 6.366 righe di codice. Le specifiche per quella modifica sono di 2.500 pagine, un volume più spesso di una rubrica. Le specifiche per il programma attuale riempiono 30 volumi ed eseguono 40.000 pagine.


3
Non impossibile. Ma altamente improbabile.
Billy ONeal,

36
Cosa ti fa pensare che FB sia privo di bug? Il modello di sicurezza e privacy di Facebook è un enorme bug. Ad esempio, l'account Facebook dei boss di Facebook è stato violato la scorsa settimana a causa di carenze nella sicurezza.
Stephen C,

6
@Elaine La filosofia di Facebook è "vai veloce e spezza le cose" ( geek.com/articles/news/… ) e hanno avuto innumerevoli bug ( facebook.com/board.php?uid=74769995908 ), inclusi molti che ho corso in me stesso. Twitter non è diverso, noto per essere spesso inattivo ( engineering.twitter.com/2010/02/anatomy-of-whale.html ) e bug come il "follow bug" ( status.twitter.com/post/587210796/… ).
Yevgeniy Brikman,

9
Non dimenticare i pali mobili. Una caratteristica di PerfectProgram 1.0 può essere un bug in 2.0
Carlos

4
@CodesInChaos: la teoria afferma che esistono programmi per i quali è impossibile dimostrare il loro comportamento. Non dice che è impossibile dimostrare il comportamento di tutti i programmi. Immagino che la maggior parte dei programmi comuni sia di tipo dimostrabile e affermare che "È impossibile che il mio codice sia privo di bug a causa del problema di arresto" è un'errata applicazione della teoria.
endolito il

98

"Programmatore zero bug" è un ossimoro, come un cantante silenzioso, ma oltre 60 anni circa di programmazione hanno prodotto alcuni frammenti di saggezza distillati, che ti renderanno un programmatore migliore, come:

  • Sii umile - stai e commetterai degli errori. Ripetutamente.
  • Sii pienamente consapevole delle dimensioni limitate del tuo cranio. Affronta il compito con piena umiltà ed evita trucchi intelligenti come la peste. [Edsger Dijkstra]
  • Combatti l' esplosione combinatoria
  • Sbarazzarsi dello stato mutevole (ove possibile). Sì, impara la programmazione funzionale.
  • Ridurre il numero di possibili percorsi del codice
  • Comprendi (la grandezza di) la dimensione degli spazi di input e output (delle tue funzioni) e cerca di ridurli per avvicinarti sempre di più al 100% di copertura del test
  • Supponi sempre che il tuo codice non funzioni, provalo altrimenti!

2
Sarei felice di dimostrare che il mio codice funziona ... ma i test possono solo provare che non lo è. Stai parlando di prove formali o stai immaginando l'attività di debug qui?
Matthieu M.

Prima risposta utile in questa discussione. @Matthieu: per ogni possibile combinazione di due byte è possibile dimostrare che una funzione restituirà un risultato corretto (ad esempio: max), che è di nuovo un byte. Puoi avere due e più di tali funzioni, e ora puoi concatenarle e ottenere un gran numero di possibili combinazioni di tali funzioni, che produrranno sempre e solo un byte. L'idea che solo tu possa provare qualcosa di sbagliato è sbagliata. Popolare, ma sbagliato.
utente sconosciuto

@Matthieu M .: I test dimostrano che le cose funzionano come previsto. Se riesci a dimostrare che tutti gli articoli stanno funzionando come ti aspetti, da lì dimostrerai di avere a che fare con comportamenti di input che non ti aspettavi. Una volta inchiodato qual è quel comportamento e quale dovrebbe essere, scrivi un nuovo test per questo. Ora fa parte del tuo comportamento previsto.
Deworde,

1
@deworde: capisco l'idea di testare, tuttavia a parte situazioni di nicchia, la maggior parte del lavoro reale che ho svolto non ha potuto essere testata in modo esaustivo, semplicemente perché il numero possibile di combinazioni era troppo grande (e non sto nemmeno aggiungendo problemi di tempistica). Quindi, a parte situazioni di nicchia, i test vanno così lontano (è comunque utile verificare che almeno il caso nominale passi!)
Matthieu M.

"evitare trucchi intelligenti come la peste" - questo da solo farebbe una buona risposta. Come è - è fantastico.
BЈовић,

25

TDD

Il punto di TDD è che non scrivi una singola riga di codice se non esiste un test che richiede quella riga di codice. E per portarlo all'estremo, inizi sempre a sviluppare una nuova funzionalità scrivendo un test di accettazione. Qui ho scoperto che scrivere test in stile cetriolo è l'ideale.

L'approccio TDD offre almeno due vantaggi.

  • Tutto il codice è scritto per risolvere una caratteristica specifica, quindi nessuna sovrapproduzione inutile.
  • Ogni volta che si modifica una riga di codice esistente, se si interrompe una funzione, si riceverà una notifica

Non dimostra zero bug, poiché ciò sarebbe impossibile (sono già stati segnalati da innumerevoli altre risposte). Ma dopo aver appreso TDD e diventare bravo in questo (sì, è anche un'abilità che ha bisogno di pratica), ho una fiducia molto maggiore nel mio codice perché è accuratamente testato. E, soprattutto, posso cambiare il codice esistente che non comprendo completamente senza preoccuparmi di interrompere la funzionalità.

Ma TDD non ti aiuta fino in fondo. Non è possibile scrivere codice privo di bug se non si comprende a fondo l'architettura del sistema e le insidie ​​di tale architettura. Ad esempio, se stai scrivendo un'applicazione Web che gestisce contemporaneamente più richieste, devi sapere che non puoi condividere dati mutabili tra più richieste (non cadere nella trappola per principianti per memorizzare nella cache i dati mutabili per migliorare le prestazioni).

Credo che i team di sviluppo che sono bravi in ​​TDD consegnino il codice con il minor numero di difetti.


19

Il fatto è che i bug sono le cose che non riconosci. A meno che tu non abbia una qualche conoscenza enciclopedica del linguaggio di programmazione / compilatore e di tutti gli ambienti in cui verrà eseguita la tua applicazione, non puoi davvero aspettarti di produrre un codice privo di bug al 100%.

È possibile ridurre il numero di bug attraverso numerosi test, ma alla fine ci sarà probabilmente un caso marginale che non verrà preso in considerazione. Joel Spolsky ha scritto un articolo particolarmente interessante sulla risoluzione dei bug .


1
+1. Nelle parole di Twisted Sister, ciò che non sai di certo può farti del male / Ciò che non riesci a vedere ti fa urlare.
Ingegnere

17

Sì, è impossibile non avere mai un bug nel tuo codice ma non è impossibile avere meno bug. L'atteggiamento che "È stupido, avrai sempre dei bug" è solo un poliziotto per evitare di ridurre il numero di bug nel tuo codice. Nessuno è perfetto, ma possiamo e dovremmo cercare di essere migliori. Nei miei sforzi per migliorare ho trovato utili i seguenti punti.

  • Questo non è facile Non migliorerai durante la notte. Quindi non scoraggiarti e non mollare.
  • Scrivi di meno e scrivi in ​​modo più intelligente. Meno codice è in genere un codice migliore. È naturale voler pianificare in anticipo e provare a creare fantastici modelli di progettazione, ma a lungo andare solo scrivere ciò di cui hai bisogno consente di risparmiare tempo e prevenire i bug.
  • La complessità è il nemico. Meno non conta se si tratta di un pasticcio oscuro e complicato. Il golf del codice è divertente ma è un inferno da capire e un inferno peggiore da eseguire il debug. Ogni volta che scrivi un codice complicato ti apri a un mondo di problemi. Mantieni le cose semplici e brevi.
  • La complessità è soggettiva. Il codice che una volta era complicato diventa semplice una volta diventato un programmatore migliore.
  • L'esperienza conta. Uno dei due modi per diventare un programmatore migliore è esercitarsi. La pratica NON è scrivere programmi che sai scrivere con facilità, è scrivere programmi che fanno un po 'male e ti fanno pensare.
  • L'altro modo per migliorare è leggere. Ci sono molti argomenti difficili nella programmazione da imparare ma non sarai mai in grado di impararli semplicemente programmando, devi studiarli. Devi leggere le cose difficili. Cose come la sicurezza e la concorrenza sono impossibili da imparare correttamente semplicemente scrivendo codice a meno che tu non voglia imparare ripulendo i disastri. Se non mi credi, guarda i problemi di sicurezza epici che avevano siti come Gawker. Se avessero preso il tempo di imparare a fare correttamente la sicurezza e non solo a fare qualcosa che funzionasse, quel casino non sarebbe mai successo.
  • Leggi i blog. Ci sono un sacco di blog interessanti là fuori che ti daranno modi nuovi e interessanti di guardare e pensare alla programmazione che ti aiuteranno a ...
  • Scopri i dettagli sporchi. I dettagli minori di come funzionano parti oscure della tua lingua e delle tue applicazioni sono molto importanti. Potrebbero contenere segreti che ti aiutano a evitare la scrittura di codice complicato o potrebbero essere parti che hanno i propri bug che devi evitare.
  • Scopri come pensano gli utenti. A volte i tuoi utenti sono completamente pazzi e lavoreranno con la tua app in modi che non capisci e non puoi prevedere. Devi metterti abbastanza in testa per conoscere le cose più strane che potrebbero provare e assicurarsi che la tua app sia in grado di gestirla.

8

Personalmente penso che lottare per una programmazione senza bug sembra essere più costoso (sia in termini di tempo che di denaro). Per raggiungere il bug zero, o addirittura il bug quasi zero, è necessario che gli sviluppatori testino accuratamente. Ciò significa che la regressione verifica tutto prima di inviare qualsiasi codice per la revisione della patch. Questo modello non mi sembra conveniente. È meglio che gli sviluppatori eseguano i test diligenti e lascino i test approfonditi al team di controllo qualità. Ecco perché:

  • Gli sviluppatori fanno schifo ai test. È vero e tu lo sai. (Sono uno sviluppatore!) Un buon team di controllo qualità troverà sempre i casi limite a cui gli sviluppatori non pensano mai.
  • Gli sviluppatori sono bravi a scrivere codice. Lascia che tornino a ciò in cui eccellono (e di solito ciò che preferiscono fare comunque).
  • Il team addetto al controllo qualità può trovare i bug relativi a più attività degli sviluppatori in un unico passaggio.

Accetta che quando scrivi il codice, ci saranno dei bug registrati contro di esso. Ecco perché hai un processo di controllo qualità ed è tutto parte dell'essere uno sviluppatore. Naturalmente questo non significa che invii qualcosa non appena scrivi il tuo ultimo punto e virgola. Devi ancora garantire la qualità del tuo lavoro, ma puoi esagerare.

Quante professioni puoi nominare che svolgono sempre il loro compito correttamente la prima volta senza revisione tra pari e / o test?


8

Zero bug? Sembra che tu abbia bisogno di Lisp (segui il percorso scettico ed evita il video musicale).

È straordinariamente difficile ottenere codice privo di bug negli ambienti di codifica tradizionali (Java, C #, PHP, ecc.). Mi concentrerei sulla produzione di codice ben testato e sottoposto a revisione paritaria in brevi iterazioni controllate.

Mantenere il codice il più semplice possibile ti aiuterà a evitare i bug.

Assicurati di utilizzare strumenti di analisi del codice (come FindBugs , PMD e così via) che, combinati con severi avvisi del compilatore, riveleranno ogni sorta di problemi con il tuo codice. Prendi nota di ciò che ti stanno dicendo, sforzati davvero di capire qual è la natura del bug, quindi prendi provvedimenti per cambiare il tuo linguaggio di programmazione in modo che risulti innaturale codificare in un modo che introduce nuovamente quel bug.


3
A volte i bug sono come mostri nascosti che vivono lì, si nascondono durante i miei test ripetuti e la revisione del proprio codice ... È davvero strano. A seconda solo dell '"occhio" umano e del "cervello" sembra impossibile toccare la linea senza bug. unit-test non è realizzabile in tutti i casi. Strumenti di analisi del codice? sembra eccitante, non l'ho mai usato, farò ricerche in questo campo.
Elaine,

Direi che hai bisogno di Ada, ma Lisp è più divertente. ;-)
Orbling

1
@Elaine Dove lavoro è un ambiente Java e il codice può essere condiviso con il team solo se è passato attraverso Findbugs e PMD. I nuovi membri del team passano attraverso cinque fasi: diniego, rabbia, contrattazione, depressione e poi accettazione. Successivamente non guardano mai indietro.
Gary Rowe,

@Gary Rowe, capisco quelle reazioni, lol, sono mai stato in un'azienda che ha avuto un ufficio di controllo qualità. I ​​dipendenti hanno controllato settimanalmente tutti i codici prodotti in quella settimana, per vedere se ogni riga di codice è conforme alla 'regola '(Non ho idea se stessero usando alcuni strumenti come Findbugs / PMD), ma suona un po' come il passo in cui ti trovi.
Elaine

1
@Gary: nessuna discussione da parte mia, ma diversi posti in cui ho lavorato trattano le violazioni di stile come equivalenti di bug. E tendevano ad avere regole di stile come "ogni classe deve dichiarare i campi statici CLS_PKG e CLS_NAME che contengono i nomi dei pacchetti e delle classi". In genere sostengo gli standard di codifica, ma non quando si trasformano in cose del genere!
TMN

8

Tutti i "Non codificare affatto". le risposte mancano completamente il punto. Inoltre, il tuo capo non sembra assolutamente essere un idiota!

Non ricordo quanto spesso ho visto programmatori che semplicemente non sapevano cosa facesse il loro codice. Il loro unico sviluppo filosofico sembrava essere tentativi ed errori (e abbastanza spesso anche copiare / incollare / modificare). Mentre tentativi ed errori sono un modo valido per affrontare alcuni problemi, spesso puoi analizzare il dominio del problema e quindi applicare una soluzione molto specifica basata sulla tua comprensione degli strumenti che usi e con un po 'di disciplina e diligenza non avrai risolto solo il problema, ma anche la maggior parte dei casi angolari (potenziali bug) prima di distribuirlo per la prima volta. Potete garantire che il codice sia privo di bug? Ovviamente no. Ma con ogni bug che incontri o leggi puoi aggiungerlo alle cose a cui potresti voler pensare la prossima volta che scrivi / cambi qualcosa. Se lo fai, otterrai di conseguenza molta esperienza su come scrivere codice quasi privo di bug. - Ci sono tonnellate di risorse disponibili su come diventare un programmatore migliore che può aiutarti nel viaggio ...

Personalmente, non commetterei mai codice in cui non riesco a spiegare ogni singola riga. Ogni riga ha un motivo per essere lì, altrimenti dovrebbe essere rimossa. Ovviamente a volte farai ipotesi sul funzionamento interno dei metodi che chiami, altrimenti dovrai conoscere la logica interna dell'intero quadro.

Il tuo capo ha perfettamente ragione a dire che dovresti capire i risultati e l'impatto del codice che scrivi sul sistema esistente. Si verificano dei bug? Sì, naturalmente. Ma questi bug saranno dovuti alla tua comprensione incompleta del sistema / strumenti con cui lavori e con ogni correzione di bug avrai una migliore copertura.


"con ogni bug che incontri o leggi puoi aggiungerlo alle cose a cui potresti voler pensare la prossima volta che scrivi / cambi qualcosa" questo è un ottimo punto. Ho creato un documento di Google relativo a bug che ho visto o codificato, solo per quello scopo.
Ben

7

Come già sottolineato correttamente dagli altri commenti, non esiste un software non banale senza bug.

Se si desidera testare il software, tenere sempre presente che i test possono solo dimostrare la presenza di bug e non la loro assenza.

A seconda del tuo dominio di lavoro, potresti provare la verifica formale del tuo software. Usando metodi formali puoi essere abbastanza sicuro che il tuo software soddisfi esattamente le specifiche.

Ovviamente questo non significa che il software fa esattamente quello che vuoi. Scrivere una specifica completa è quasi impossibile anche in quasi tutti i casi. In pratica sposta il luogo in cui possono verificarsi errori dall'implementazione alle specifiche.

Quindi, a seconda della tua definizione di "bug", puoi provare la verifica formale o semplicemente cercare di trovare quanti più bug puoi nel tuo software.


6

Né scrivere niente di più complicato di "Hello World!" o se lo dici a tutti di non usarlo mai.

Chiedi al tuo capo alcuni esempi di questo cosiddetto codice privo di bug.


5

Sono d'accordo con gli altri. Ecco come vorrei affrontare il problema

  • Ottieni un tester. Vedi il Joel Test per il perché.
  • Utilizzare ampiamente le librerie; probabilmente è stato eseguito il debug migliore. Sono un grande fan di CPAN per Perl.

1
... ma se usi le librerie, assicurati che i loro bug non possano trascinarti verso il basso (ad esempio, avendo il sorgente in modo da poterlo controllare o correggere tu stesso i bug se necessario).
Millenomi,

5

Puoi sforzarti di essere un programmatore zero bug. Mi sforzo di essere un programmatore zero bug ogni volta che scrivo codice. Tuttavia, non lo so

  • coinvolgere più tecniche di test (oltre a ATDD)
  • creare verifiche formali del nostro software
  • avere un team di controllo qualità separato
  • eseguire analisi approfondite su ogni modifica apportata alla base di codice
  • usa un linguaggio che tende maggiormente alla sicurezza e alla cautela

Non faccio queste cose perché sono proibitive in termini di costi per il software che scrivo. Se facessi queste cose, probabilmente sarei più avanti verso zero bug, ma non avrebbe senso per gli affari.

Creo strumenti interni che gran parte della nostra infrastruttura utilizza. I miei standard per test e codifica sono alti. Tuttavia, c'è un equilibrio. Non mi aspetto zero bug perché non posso avere persone che dedicano quel tipo di tempo a un solo lavoro. Le cose potrebbero essere diverse se stavo creando il software per controllare una macchina a raggi X, motori a reazione, ecc. Se il mio software si rompe, non ci sono vite sulla linea, quindi non ci impegniamo in questo livello di affidabilità.

Abbinerei il livello di affidabilità all'uso previsto del software. Se stai scrivendo un codice che lo shuttle della NASA utilizzerà, forse la tolleranza zero è ragionevole. Hai solo bisogno di aggiungere un sacco di pratiche aggiuntive e molto costose.


4

Penso che un buon primo passo per diventare un programmatore "zero-bug" sia quello di cambiare il tuo atteggiamento nei confronti dei bug. Invece di dire "accadono", "ottenere QA e tester migliori" o "gli sviluppatori fanno schifo durante i test", dicono:

I bug non sono accettabili e farò tutto il possibile per eliminarli.

Una volta che questo diventa il tuo atteggiamento, i bug scenderanno rapidamente. Nella tua ricerca per trovare modi per eliminare i bug, ti imbatterai in test-driven-development. Troverai molti libri, post di blog e persone che offrono consigli gratuiti su tecniche migliori. Vedrai l'importanza di migliorare le tue abilità attraverso la pratica (come programmare i kata o provare nuove cose a casa). Inizierai a lavorare meglio perché inizierai a lavorare sul tuo mestiere a casa. E, si spera, quando vedrai che è possibile scrivere un buon software, la tua passione per il tuo mestiere crescerà.


2

In un certo senso, il tuo capo ha ragione. È possibile scrivere software che si avvicina a zero bug.

Ma il problema è che il costo per scrivere programmi (quasi) a zero bug è proibitivamente alto . Devi fare cose come:

  • Usa le specifiche formali delle tue esigenze. Formale, come in uso di Z o VDM o qualche altra notazione matematicamente sana.

  • Usa le tecniche di dimostrazione del teorema per dimostrare formalmente che il tuo programma implementa le specifiche.

  • Crea suite estese di unità, regressione e test di sistema e cablaggi per testare in ogni modo la presenza di bug. (E questo non è di per sé sufficiente.)

  • Chiedi a molte persone di esaminare i requisiti (formali e informali), il software (e le prove). test e implementazioni.

È estremamente improbabile che il tuo capo sia disposto a pagare per tutto questo ... o sopportare il tempo necessario per fare tutto.


1

Ho raggiunto lo stato "zero bug". Dico ai miei utenti che è una funzionalità non documentata, o che stanno chiedendo una nuova funzionalità e quindi è un miglioramento. Se nessuna di queste risposte è accettata, dico semplicemente loro che non hanno capito le proprie esigenze. Pertanto, non ci sono bug. I programmatori sono perfetti.


1

Ecco i passaggi per creare un programma libero da bug:

  1. Non iniziare mai la codifica a meno che tu non abbia SPECIFICHE NON AMMESSE per la tua funzionalità.
  2. NON TESTARE o, in caso contrario, NON FARE AFFIDAMENTO ALLE PROVE per rilevare difetti nel software.
  3. Applicare tutte le RISPOSTE dai difetti rilevati durante i test, le revisioni e la produzione a un processo e agli sviluppatori che hanno inserito il difetto al primo posto. Eliminare completamente tutti i componenti difettosi non appena vengono rilevati i difetti. Aggiorna le tue liste di controllo e riqualifica i tuoi sviluppatori in modo che non commettano nuovamente errori del genere.

I test possono solo dimostrare che hai dei bug, ma di solito è inutile provare il contrario. Per quanto riguarda il feedback, se hai una macchina per fare monete che produce monete e ogni moneta da 10s in media ha un difetto. Puoi prendere quella moneta, appiattirla e reinserirla nella macchina. la moneta che ha rivelato che il bianco riciclato non sarà altrettanto buono, ma forse accettabile. ogni moneta da 100s dovrà essere timbrata 2 volte e così via. Sarebbe più facile riparare la macchina?

Purtroppo le persone non sono macchine. Per rendere il programmatore efficace e privo di difetti devi investire molto tempo, allenandoti e ripetendo ogni difetto commesso. Gli sviluppatori devono essere formati su metodi di verifica formali che sono spesso difficili da imparare e applicare nella pratica. Anche l'economia dello sviluppo del software sta lavorando contro di essa - investiresti 2 anni nella formazione di un programmatore che può fare meno difetti solo per vederlo saltare da un altro datore di lavoro? Puoi acquistare una macchina che rende perfette monete o assumere altre 10 scimmie in codice per creare un gruppo di test allo stesso costo. Puoi percepire questo processo esaustivo come la tua "macchina", la tua risorsa: investire in una formazione approfondita di sviluppatori eccellenti non paga.

Presto imparerai come sviluppare software di qualità accettabile, ma probabilmente non sarai mai uno che è privo di difetti per una semplice ragione che non esiste mercato per gli sviluppatori che realizzano un codice perfetto perché è lento.


+1 per menzionare specifiche non ambigue. So che si tratta di un argomento di 2 anni, ma devo sottolineare che la tua è l'unica risposta per sottolineare che è errato supporre che un bug equivale a un errore di programmazione.
Brandon,

0

Programma difensivo: http://en.wikipedia.org/wiki/Defensive_programming

Se qualcuno segue le convenzioni della programmazione in modo difensivo, i cambiamenti saranno facilmente rintracciabili. Combina questo con rigide segnalazioni di bug durante lo sviluppo e una solida documentazione, come con doxygen, e dovresti essere in grado di sapere esattamente cosa sta facendo tutto il tuo codice e correggere eventuali bug che si presentano, in modo molto efficiente.


0

Questo potrebbe essere il risultato dell'incomprensione di una buona metodologia e non solo della stordimento generico?

Quello che voglio dire è che è possibile che il tuo capo abbia sentito parlare di "metodologia zero difetti" (vedi sezione n. 5) e non si sia preoccupato di capire cosa significasse?
Certo, è inopportuno per la gestione posticipare lo sviluppo di nuove funzionalità, a favore di bug che non avresti dovuto inserire ...
E, naturalmente, ciò minaccia il suo bonus, quindi ovviamente non ne otterrai uno perché "i bravi programmatori non lo fanno avere bug "...

Va bene creare bug, purché sia ​​possibile trovarli e risolverli (entro limiti ragionevoli, ovviamente).


0

Uno dei concetti fondamentali del test del software è che non si può MAI essere assolutamente sicuri che il programma sia perfetto. Puoi convalidarlo per sempre, ma ciò non dimostra mai che il programma sia completo perché diventa rapidamente impossibile persino testare tutte le combinazioni input / variabili.

Il tuo capo sembra uno di quelli che "non capisce cosa c'è di così difficile nella programmazione, dato che è solo digitando"


0

Se assumiamo che grandi case di software sappiano come ottenere sviluppatori di prim'ordine (come nel programmatore zero bug ) possiamo dedurre che il software di Microsoft deve essere privo di bug. Eppure sappiamo che è lontano dalla verità.

Sviluppano il loro software e quando raggiungono un certo livello di bug a bassa priorità, rilasciano semplicemente il prodotto e risolvono quelli successivi.

A meno che tu non stia sviluppando qualcosa di più complesso di una semplice calcolatrice, non è possibile evitare tutti i bug insieme. Al diavolo persino la NASA ha ridondanza anche sui propri veicoli e bug. Sebbene abbiano test molto rigorosi per evitare guasti catastrofici. Tuttavia, hanno anche dei bug nel loro software.

Gli errori sono inevitabili, così come la natura umana deve sbagliare.

Non avere bug è come avere un sistema sicuro al 100%. Se un sistema è sicuro al 100%, sicuramente non è più utile (probabilmente si trova all'interno di tonnellate e tonnellate di cemento e non è affatto collegato all'esterno. Non cablato né wireless. Così come non esiste un sistema perfettamente sicuro , non esiste un sistema complesso privo di bug.


-1

Vedo solo risposte su di noi essere umani e inclini a sbagliare, il che è molto vero ... ma vedo la tua domanda da un altro punto di vista.

Penso che tu possa scrivere programmi senza bug, ma quelli in genere sono programmi che hai già scritto 10 o 12 volte. La tredicesima volta che scrivi lo stesso programma da zero, sai già come farlo: conosci il problema, conosci le tecniche, conosci le librerie, il linguaggio ... lo vedi nella tua mente. Tutti i modelli sono lì, a tutti i livelli.

Questo mi succede con programmi molto semplici perché insegno programmazione. Sono semplici per me, ma difficili per gli studenti. E non sto parlando di soluzioni a problemi che ho fatto molte, molte volte alla lavagna. Certo che conosco quelli. Intendo programmi a circa 300 righe che risolvono qualcosa usando concetti che conosco molto bene (i concetti a cui insegno). Scrivo questi programmi senza pianificazione e funzionano e sento di conoscere tutti i dettagli, non ho bisogno del TDD. Ottengo un paio o tre errori di compilazione (principalmente errori di battitura e altre cose del genere) e basta. Posso farlo per piccoli programmi e credo anche che alcune persone possano farlo per programmi più complicati. Penso che persone come Linus Torvalds o Daniel J. Bernstein abbiano una tale chiarezza mentale, sono le più vicine che puoi ottenere a un programmatore privo di bug. Se tucapire le cose in profondità penso che tu possa farlo. Posso farlo solo per programmi semplici, come ho detto.

La mia convinzione è che se provi sempre a fare programmi molto al di sopra del tuo livello (ho passato anni a farlo), ti confonderai e commetterai errori. Grandi errori come quelli in cui improvvisamente ti rendi conto che la tua soluzione non può funzionare, quando finalmente capisci il problema, e devi apportare modifiche così complicate che potrebbero impedirti di risolvere il tuo problema o rendere il codice terribile. TDD è per questi casi, credo. Sai che non affronti il ​​problema che stai affrontando e quindi metti test ovunque per assicurarti di avere una base solida. Il TDD non risolve la visione di 10.000 piedi, però. Potresti camminare sempre in cerchio con un codice perfettamente pulito.

Tuttavia, se provi a fare qualcosa di nuovo ma che è appena sopra il tuo livello, potresti ottenere il tuo programma perfetto o quasi perfetto. Penso che sia davvero difficile sapere quali sono i programmi nella tua "frontiera della conoscenza", ma in teoria è il modo migliore per imparare. In realtà, riscrivo molto i programmi da zero. Alcune persone lo fanno, ma hai bisogno di molto tempo e pazienza perché la terza volta che ripeti un programma non banale non ti ecciti come la prima volta.

Quindi il mio consiglio è: non pensare di aver capito qualcosa fino a quando non puoi scrivere un programma privo di bug proprio per quella cosa. E poi prova a combinare due di quei concetti che conosci profondamente nello stesso programma. Sono quasi sicuro che riuscirai a farlo bene la prima volta. Uno dei modi migliori è quello di riscrivere software non banale, cosa che per la prima volta è stato un grande sforzo (lo sto facendo ora con le app Android). Ogni volta che ricomincio cambio qualcosa o aggiungo qualcosa, solo per aggiungere un po 'di divertimento, e posso dirti che sto migliorando sempre meglio ... forse non privo di bug ma davvero orgoglioso.


-1

bug imho e artefatti improvvisi e misteriosi dell'algoritmo devono comparire durante il processo di codifica: ispirano e forzano l'evoluzione del codice.
tuttavia è possibile (di solito dopo alcuni test) controllare ogni variabile che potrebbe essere utilizzata prima della dichiarazione, gestire ogni errore ovunque appaia - rendere il programma zero-bug ... fino a quando non si riceve una richiesta per una funzionalità considerata impossibile quando si parlava di architettura del programma;)


1
Non lo so - sembra un tipo di approccio mistico alla programmazione, che è un campo di impegno chiaramente non mistico. Non programmare in modo efficace attraverso tentativi ed errori o usando un'asta divinatoria. Progetta le cose intenzionalmente. E i bug continueranno a spuntare. Quindi li aggiusti. Ma innanzitutto progettate intenzionalmente il vostro codice in modo che non contenga bug.
Craig,

-1

Forse pensa di più alla natura dei bug che ottieni. Se i bug sono generalmente svantaggi minori, sarebbe utile concentrarsi su test migliori e leggere un po 'di correzione del codice.

Se i bug tendono ad essere dovuti a decisioni di programmazione non ottimali, tuttavia, forse è necessario impegnarsi maggiormente per progettare meglio. In questo caso, penso che sia possibile dipendere troppo dai test per aumentare la qualità del software, perché l'applicazione di una patch a un codice difettoso può solo rendere più complicata la manutenzione futura. Da un lato ottieni meno bug quando li trovi e li risolvi, ma dall'altro prepari il terreno per futuri bug.

Un modo per giudicare se hai un problema con sviste o un problema con la progettazione potrebbe essere quello di considerare quanto sforzo è necessario per correggere i bug. Se le correzioni tendono ad essere grandi, o ritieni di non capirle bene, questo indica la figura nella progettazione del codice che può essere migliorata.

Il fatto che penso dipenda da una sorta di buon gusto per il codice, che puoi sviluppare con la pratica e la revisione, e leggere persone con problemi simili.

In definitiva, è inutile non aspettarsi alcun bug, ma non c'è nulla di male nel cercare di ridurre il numero di bug a meno che non lo si abbia già a un livello basso, e quindi diventa un compromesso tra il tuo tempo e il tempo di chi trova bug che non catturi.


-2

Se voglio dire: "zero bug durante la scrittura del codice" -> è un bel obiettivo ma abbastanza impossibile.

Ma se intendi: "zero bug sul codice consegnato" -> è possibile e ho lavorato in tali ambienti.

Tutto ciò di cui hai bisogno è: una qualità del codice follemente elevata e una copertura dei test vicina al 100% (test unitari + test di collaudo + test di integrazione).

Secondo me il miglior libro da imparare è: GOOS . Ma ovviamente un libro non è abbastanza. Devi andare in un gruppo di utenti e discuterne. Corsi, conferenze, ecc. La qualità a zero bug non è facile.

Prima di tutto hai bisogno di un capo che sia davvero interessato all'alta qualità e disposto a pagare per questo.


-3

Soluzione del programmatore:

  • Interrompere la programmazione.
  • Costruisci un computer meccanico.
  • Sostituirlo ogni 5 anni in modo che l'usura meccanica non entri in gioco.

Soluzione dell'utente:

  • Smetti di usare i computer.
  • Fai tutto manualmente.
  • Avere sempre una seconda persona ricontrollare i risultati.

-3

Sono d'accordo che per essere un programmatore zero-bug non puoi semplicemente programmare / codificare. Fa parte della vita di ogni programmatore incontrare e sviluppare bug. Nessuno sviluppatore esperto può dire, a memoria, che non hanno mai riscontrato un bug nel loro codice.


-4

Abbinalo a un altro ingegnere. Scrivi un test fallito. Fai in modo che ogni carattere che digiti sia necessario per superare il test fallito. Rifattorizza il codice per renderlo più semplice. Scrivi un altro test fallito, e così via.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.