it-swarm.it

Come essere un programmatore zero bug?

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?

168
Elaine

Non codificare affatto.

Questo è l'unico modo in cui puoi essere un programmatore a 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.

365
wildpeaks

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. Mi viene in mente software Space Shuttle . 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 - ciascuna lunga 420.000 righe - avevano un solo errore ciascuna. Le ultime 11 versioni di questo software hanno totalizzato 17 errori.

Prendi l'aggiornamento del software per consentire alla navetta 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.

124
CodesInChaos

"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]
  • Lotta 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!
98
Maglob

TDD

Il punto di TDD è che non si scrive 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 cetriolo test di stile è 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. Per esempio. se stai scrivendo un'applicazione web che gestisce più richieste contemporaneamente, 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.

25
Pete

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 piacevole su bug-fixing .

19
user7007

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 scrivendo semplicemente 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 avuto 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.
17
AmaDaden

Zero bug? Sembra hai bisogno di LISP (segui il percorso scettico ed evita il video musicale).

È straordinariamente difficile ottenere un codice privo di bug negli ambienti di codifica tradizionali (Java, C #, PHP, ecc.). Mi concentrerei su producendo codice ben testato e rivisto da pari in iterazioni controllate in breve.

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

Assicurati di utilizzare strumenti di analisi del codice (come FindBugs , PMD e così via) che, combinato con severi avvisi del compilatore, rivelerà ogni sorta di problema 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.

8
Gary Rowe

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 Edge a cui gli sviluppatori non pensano mai.
  • Gli sviluppatori sono bravi a scrivere codice. Lascia che tornino a ciò che fanno in Excel (e di solito quello 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 una procedura 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
Sebastien Martin

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. Naturalmente a volte farai delle 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.

8
Patrick Klug

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.

7
FabianB

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.

6
JeffO

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.
5
Brian Carlton

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 (diverse da quelle 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 unico 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 non funziona, non ci sono vite sulla linea, quindi non ci impegniamo in questo livello di affidabilità.

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

5
dietbuddha

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 cose "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 pratica (come codificare i kata o provare nuove cose a casa). Inizierai a lavorare meglio perché inizierai a lavorare sul tuo mestiere a casa. E, si spera, una volta che lo vedi è è possibile scrivere un buon software , la tua passione per il tuo mestiere crescerà.

4
Darren

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

Ma il problema è che costo di scrivere programmi (quasi) a zero bug è proibizionalmente 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 (formale e informale), 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.

2
Stephen C

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 che non hanno capito le loro esigenze. Pertanto, non ci sono bug. I programmatori sono perfetti.

1
angryITguy

Ecco i passaggi per creare un programma libero da bug:

  1. Non iniziare mai la codifica a meno che tu non abbia SPECIFICHE NON AMMISSIBILI 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 si dispone di 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 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
Alexei Polkhanov

Se assumiamo grandi software house sappiamo come ottenere sviluppatori di prim'ordine (come in programmatore zero bug ) possiamo dedurre che il software Microsoft deve essere senza 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 loro veicoli e sui suoi bug. Sebbene abbiano test molto rigorosi per evitare guasti catastrofici. Tuttavia, hanno anche dei bug nel loro software.

I bug sono inevitabili così come la natura umana è errata.

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.

0
Robert Koritnik

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 rigorose 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
Jason McCarrell

Questo potrebbe essere il risultato di un'incomprensione di una metodologia buona , e non solo di una stordita generica?

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

Va bene creare bug, finché puoi trovarli e risolvili (entro limiti ragionevoli, ovviamente).

0
AviD

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
SpacePrez