Come essere un programmatore di bug zero? [chiuso]

Non scrivere affatto.

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

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.

Zero bug è impossibile per un programma non banale.

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

This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long - had just one error each. The last 11 versions of this software had a total of 17 errors.

Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specifications for that one change run 2,500 pages, a volume thicker than a phone book. The specifications for the current program fill 30 volumes and run 40,000 pages.

"Il programmatore Zero-bug" è un ossimoro, come un cantante silenzioso, ma oltre 60 anni di programmazione ha prodotto alcuni pezzi di saggezza distillati, che ti renderanno un programmatore migliore, come ad esempio:

• Sii umile - sei 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 esplosione combinatoria
• Sbarazzarsi dello stato mutabile (dove mai possibile). Sì, apprendi la programmazione funzionale.
• Riduci il numero di possibili percorsi di codice
• Comprendi (la grandezza di) la dimensione dell'ingresso & spazi di output (delle tue funzioni) e cerca di ridurli per avvicinarti sempre di più al 100% di copertura di test
• Assumi sempre che il tuo codice non funzioni, provalo diversamente!

TDD

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

L'approccio TDD offre almeno due vantaggi.

• Tutto il codice è scritto per risolvere una caratteristica specifica, quindi nessuna sovrapproduzione non necessaria.
• Ogni volta che cambi una linea di codice esistente, se interrompi una funzione, riceverai una notifica

Non dimostra zero bug, poiché ciò sarebbe impossibile (sono già stati segnalati da innumerevoli altre risposte). Ma dopo aver imparato TDD e diventare bravo a farlo (sì, è anche un'abilità che richiede pratica), ho una fiducia molto più elevata nel mio codice perché è completamente testato. E, ancora più importante, posso modificare il codice esistente che non comprendo completamente senza preoccuparmi di rompere le funzionalità.

Ma TDD non ti aiuta fino in fondo. Non è possibile scrivere codice senza errori 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 contemporaneamente più richieste, devi sapere che non puoi condividere dati mutabili tra più richieste (non cadere nel trappola per principianti per memorizzare dati mutabili per migliorare le prestazioni).

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

Il fatto è che i bug sono le cose che non riconoscono. 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 errori al 100%.

Puoi ridurre il tuo numero di bug attraverso molti test, ma alla fine ci sarà probabilmente qualche caso marginale che non verrà tenuto in considerazione. Joel Spolsky ha scritto un articolo particolarmente carino su risoluzione dei bug .

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

• Non è facile. Non migliorerai durante la notte. Quindi non scoraggiarti e non ti arrendere.
• Scrivi 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 design, ma a lungo andare solo scrivere ciò che ti serve per risparmiare tempo e prevenire i bug.
• La complessità è il nemico. Meno non conta se si tratta di un oscuro caos complicato. Il codice golf è divertente ma è un inferno da capire e un peggio inferno da debugare. Ogni volta che scrivi 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 è praticare. La pratica NON è scrivere programmi che sai scrivere con facilità, è scrivere programmi che ti fanno un po 'male e farti riflettere.
• L'altro modo per migliorare è leggere. Nella programmazione ci sono molti argomenti difficili da imparare, ma non sarai mai in grado di apprenderli semplicemente programmando, devi studiarli. Devi leggere le cose difficili. Cose come sicurezza e concorrenza sono impossibili da imparare correttamente solo scrivendo il codice, a meno che non si voglia imparare ripulendo i disastri. Se non mi credi, guarda i siti di sicurezza epici come Gawker. Se hanno avuto il tempo di imparare come fare correttamente la sicurezza e non solo creare qualcosa che funzionasse, quel disastro non sarebbe mai accaduto.
• Leggi i blog. Ci sono un sacco di blog interessanti là fuori che ti daranno nuovi e interessanti modi per guardare e pensare di programmare questo ti aiuterà a ...
• Scopri i dettagli sporchi. I dettagli minori di come parti oscure della tua lingua e applicazioni funzionano sono molto importanti. Potrebbero contenere segreti che ti aiutano a evitare di scrivere codice complicato o potrebbero essere parti in cui ci sono dei bug da evitare.
• Scopri come pensano gli utenti. A volte i tuoi utenti sono completamente fuori di testa e lavoreranno con la tua app in un modo che non comprendi e non puoi prevedere. Hai bisogno di entrare nella loro testa abbastanza per conoscere le cose estranee che potrebbero provare e assicurarti che la tua app possa gestirli.

Personalmente penso che la ricerca di una programmazione senza bug sia più costosa (sia in termini di tempo che di denaro). Al fine di raggiungere zero bug, o anche quasi zero bug, è necessario avere gli sviluppatori testare a fondo. Questo significa test di regressione tutto prima di inviare qualsiasi codice per la revisione delle patch. Questo modello non mi sembra redditizio. Fai meglio a fare in modo che gli sviluppatori conducano due verifiche diligenti e lasci il test approfondito al team di controllo qualità. Ecco perché:

• Gli sviluppatori fanno schifo ai test. È vero e tu lo sai. (Sono uno sviluppatore!) A un buon team di QA troverà sempre i casi limite a cui gli sviluppatori non pensano mai.
• Gli sviluppatori sono bravi a programmare. Lascia che tornino a quello in cui eccellono (e di solito ciò che preferiscono fare comunque).
• Il team addetto al QA può trovare bug relativi a più attività dello sviluppatore 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à e tutto fa parte dello sviluppo. Ovviamente questo non significa che devi inviare qualcosa non appena scrivi il tuo ultimo punto e virgola. Hai ancora bisogno di garantire la qualità del tuo lavoro, ma puoi esagerare.

Quante professioni puoi nominare che ottengono sempre il loro compito fatto per la prima volta senza revisione e / o test?

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

È straordinariamente difficile ottenere codice privo di bug negli ambienti di codifica mainstream (Java, C #, PHP, ecc.). Mi concentrerei su produrre codice ben testato e sottoposto a peer review in iterazioni controllate a breve.

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

Assicurati di utilizzare strumenti di analisi del codice (ad esempio FindBugs , PMD e così via) che, combinato con gli avvertimenti del compilatore, rivelerà ogni tipo di problema con il tuo codice. Prendi nota di ciò che ti stanno dicendo, sforzati davvero di capire qual è la natura del bug e poi prendi le misure per cambiare il tuo linguaggio di programmazione in modo che non sia naturale codificare in un modo che introduce di nuovo quel bug.

Tutti i "Non scrivere codice". le risposte mancano completamente il punto. Inoltre, il tuo capo non sembra essere un deficiente!

Non riesco a ricordare quante volte ho visto programmatori che semplicemente non sapevano cosa fa il loro codice. La loro unica filosofia di sviluppo sembrava essere prova ed errore (e molto spesso anche copia / incolla / modifica). Mentre la sperimentazione e l'errore sono un modo valido per risolvere alcuni problemi, spesso è possibile analizzare il dominio del problema e quindi applicare una soluzione molto specifica basata sulla comprensione degli strumenti che si utilizzano e con un po 'di disciplina e diligenza che non si avranno risolto solo il problema ma anche la maggior parte dei casi d'angolo (potenziali bug) prima di distribuirlo per la prima volta. Puoi garantire che il codice sia privo di bug? Ovviamente no. Ma con ogni bug che incontri o leggi su di te puoi aggiungerlo alle cose a cui potresti voler pensare la prossima volta che scrivi / cambi qualcosa. Se lo farai, otterrai di conseguenza molta esperienza su come scrivere codice praticamente privo di bug. - Ci sono tonnellate di risorse disponibili su come diventare un programmatore migliore che può aiutarti nel viaggio ...

Personalmente, non inserirò mai codice in cui non posso spiegare ogni singola riga. Ogni linea ha una ragione per essere lì, altrimenti dovrebbe essere rimossa. Ovviamente a volte farai delle supposizioni sul funzionamento interno dei metodi che chiami, altrimenti dovresti conoscere la logica interna dell'intero framework.

Il tuo capo ha perfettamente ragione nel dire che dovresti capire i risultati e l'impatto del codice che scrivi sul sistema esistente. Bugs occcur? 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 copertura migliore.

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

Se vuoi testare il software, tieni sempre presente che i test possono solo dimostrare la presenza di bug, 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.

Questo naturalmente non significa che il software faccia esattamente quello che vuoi. Anche la scrittura di una specifica completa non è possibile in quasi tutti i casi. In pratica sposta il punto in cui possono verificarsi errori dall'implementazione alle specifiche.

Quindi, in base alla tua definizione di "bug", puoi provare la verifica formale o semplicemente provare a trovare il maggior numero possibile di errori nel tuo software.

O non scrivere niente di più complicato di "Hello World!" o se dici a tutti di non usarlo.

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

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

• Richiedi un tester. Vedi il test di Joel per il perché.
• Utilizza le librerie in modo estensivo; probabilmente sono stati eseguiti il debugging meglio. Sono un grande fan di CPAN per Perl.

Puoi sforzarti di essere un programmatore di bug zero. Mi sforzo di essere un programmatore di bug zero ogni volta che sto scrivendo il codice. Tuttavia, io non

• attuare più tecniche di test (altro ATDD)
• creare verifiche formali del nostro software
• avere un team di controllo qualità separato
• esegui analisi approfondite su ogni modifica apportata al codice base
• usa un linguaggio più incline alla sicurezza e alla cautela

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

Creo strumenti interni utilizzati da gran parte della nostra infrastruttura. I miei standard per i test e la codifica sono alti. Tuttavia, c'è un equilibrio. Non mi aspetto zero bug perché non posso avere persone che mettono quel tipo di tempo in un pezzo di lavoro. Le cose potrebbero essere diverse se stessimo creando il software per controllare una macchina a raggi X, motori a reazione, ecc. Nessuna vita è in gioco se il mio software si rompe, quindi non ci impegniamo in questo livello di sicurezza.

Vorrei abbinare il livello di sicurezza all'uso previsto del software. Se stai scrivendo il codice che la navetta della NASA userà, forse la tolleranza zero è ragionevole. Hai solo bisogno di aggiungere un sacco di pratiche aggiuntive e molto costose.

Penso che un buon primo passo per diventare un programmatore "zero-bug" sia cambiare il tuo atteggiamento nei confronti degli insetti. Invece di dire "accadono", "migliora il controllo qualità e i tester" o "gli sviluppatori fanno schifo ai test", dì:

I bug non sono accettabili e farò tutto quanto è in mio potere 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 uno sviluppo basato sui test. 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 codificare i kata o provare nuove cose a casa). Inizierai a lavorare meglio perché inizierai a lavorare sulla tua imbarcazione a casa. E, si spera, una volta che vedi che è possibile scrivere buoni software , la tua passione per il tuo mestiere crescerà.

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

Ma il problema è che il costo dei programmi di scrittura (quasi) zero-bug è proibitivamente alto . Devi fare cose come:

• Utilizza le specifiche formali dei tuoi requisiti. Formale, come in uso di Z o VDM o qualche altra notazione dal punto di vista matematico.

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

• Crea vasti gruppi di test di unità, regressione e sistema per testare tutti i tipi di bug. (E questo non è sufficiente di per sé.)

• Chiedi a molte persone di esaminare i requisiti (formale e informale), il software (e le prove). test e distribuzioni.

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

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

Ecco i passaggi per creare un programma gratuito di bug:

1. Non iniziare mai la codifica se non hai SPECIFICHE UNAMBIGUOSE per la tua funzionalità.
2. NON TEST o O se NON FATE AFFIDAMENTO SU TEST per rilevare difetti nel software.
3. Applicare tutte le RISPOSTE da difetti scoperti durante test, recensioni e produzione in un processo e sviluppatori che hanno inserito il difetto al primo posto. Eliminare completamente tutti i componenti difettosi non appena vengono rilevati dei difetti. Aggiorna le tue liste di controllo e riqualifica i tuoi sviluppatori in modo che non commettano errori del genere.

I test possono solo dimostrare di avere dei bug, ma di solito è inutile provare il contrario. Per quanto riguarda il feedback - se si dispone di una macchina per la produzione di monete che produce monete e ogni moneta da 10 pollici ha un difetto. Puoi prendere quella moneta, appiattirla e inserirla nuovamente nella macchina. una moneta che ha fatto capire che lo spazio vuoto riciclato non sarà altrettanto buono, ma forse accettabile. ogni moneta da 100 deve essere ritoccata 2 volte e così via. Sarebbe più semplice riparare la macchina?

Sfortunatamente le persone non sono macchine. Per diventare un programmatore bravo e privo di difetti, devi investire molto tempo, allenandoti e procedendo con iterazione su ogni difetto prodotto. Gli sviluppatori devono essere formati su metodi di verifica formale che sono spesso difficili da apprendere e applicare nella pratica. Anche l'economia dello sviluppo del software sta lavorando contro di essa: investirai 2 anni nell'allenamento di un programmatore che può fare meno difetti solo per vederlo saltare a un altro datore di lavoro? Puoi comprare macchine che realizzano monete perfette o assumere 10 scimmie di codice in più per creare una serie di test allo stesso costo. Puoi percepire questo processo esaustivo come la tua "macchina", il tuo patrimonio - investire in una formazione approfondita di sviluppatori eccellenti non ti ripaga.

Molto 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 un mercato per gli sviluppatori che realizzano codice perfetto perché è lento.

Programma in modo difensivo: link

Se qualcuno segue le convenzioni della programmazione in modo difensivo, allora i cambiamenti saranno facilmente rintracciabili. Combina questo con report di bug rigorosi 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.

Questo potrebbe essere il risultato di un fraintendimento di una buona metodologia, e non solo di una spudoratezza generica?

Ciò che intendo è che è possibile che il tuo capo abbia sentito parlare di "metodo zero difetti" (vedere la sezione n.5), e non si è preoccupato di capire cosa significasse?
Ovviamente, è scomodo per il management posticipare lo sviluppo di nuove funzionalità, a favore di bug che tu non avresti dovuto inserire ...
E ovviamente, questo minaccia il suo bonus, quindi ovviamente non ne riceverai uno perché "i bravi programmatori non hanno bug" ...

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

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

Il tuo capo sembra uno di quelli che "non capisce cosa sia tanto difficile programmare, dato che è solo digitando"

Se supponiamo che le grandi case di software sappiano come ottenere sviluppatori di prim'ordine (come in programmatore di bug zero ) possiamo dedurre che il software Microsoft deve essere senza errori. 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 errori tutti insieme. Anche la NASA ha ridondanza sui loro veicoli e bug. Anche se hanno test molto rigorosi per evitare guasti catastrofici. Ma nonostante ciò hanno bug nel loro software.

I bug sono inevitabili proprio come la natura umana da errare.

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 è collegato affatto all'esterno. Non cablato né wireless. Così come non esiste un sistema perfettamente sicuro , non esiste un sistema complesso privo di errori.

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

Penso che puoi scrivere programmi senza bug, ma quelli in genere sono programmi che hai scritto già 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 in la tua mente. Tutti i modelli sono lì, a tutti i livelli.

Questo mi succede con programmi molto semplici perché insegno alla programmazione. Sono semplici per me, ma difficili per gli studenti. E non sto parlando di soluzioni ai problemi che ho fatto molte, molte volte nella lavagna. Certo che li conosco. Voglio dire ~ programmi di 300 righe che risolvono qualcosa usando concetti che conosco molto bene (i concetti che insegno). Scrivo questi programmi senza pianificazione e funzionano, e sento di conoscere tutti i dettagli, non ho assolutamente bisogno di 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 hanno una tale chiarezza mentale, sono le più vicine a un programmatore privo di bug. Se tu capisci le cose profondamente, penso che tu possa farcela. Posso farlo solo per programmi semplici, come ho detto.

La mia convinzione è che se cerchi sempre di fare programmi che sono molto al di sopra del tuo livello (ho passato anni facendo proprio questo), ti confonderai e commetterai degli 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 orribile. TDD è per questi casi, credo. Sapete che non si tratta del problema che si sta affrontando e quindi si mettono i test dappertutto per assicurarsi di avere una base strong. Tuttavia, TDD non risolve la visione di 10.000 piedi. Puoi camminare in cerchio con codice perfettamente pulito tutto il tempo.

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

Quindi il mio consiglio è: non pensare di aver capito qualcosa finché non puoi scrivere un programma privo di bug solo per quella cosa. E poi prova a combinare due di quei concetti che conosci profondamente nello stesso programma. Sono quasi sicuro che lo farai bene la prima volta. Uno dei modi migliori è riscrivere il software non banale, cosa che ha richiesto molto impegno la prima volta (lo sto facendo con le app Android in questo momento). Ogni volta che ricomincio cambio qualcosa o aggiungo cose, solo per aggiungere un po 'di divertimento, e posso dirti che sto migliorando sempre di più ... forse non sono privo di bug ma sono davvero orgoglioso.

I bug imho e gli improvvisi, misteriosi artefatti dell'algoritmo devono apparire durante il processo di codifica: ispirano e forzano l'evoluzione del codice. tuttavia è possibile (di solito dopo alcuni test) controllare tutte le variabili che potrebbero essere utilizzate prima della dichiarazione, per gestire ogni errore ovunque possa apparire - per rendere il programma zero-bug ... fino a quando non ricevi una richiesta per una funzione era considerato impossibile quando stavi discutendo dell'architettura del programma;)

Forse pensa di più sulla natura degli errori che ottieni. Se i bug sono in genere sviste minori, concentrarsi su test migliori e un po 'di correzione di codice potrebbe aiutare.

Se i bug tendono a essere dovuti a scelte di programmazione subottimali, tuttavia, è necessario un maggiore impegno per una progettazione migliore. In questo caso, penso che sia possibile dipendere troppo dai test per migliorare la qualità del software, perché l'applicazione di una patch a un codice difettoso può rendere più complicata la manutenzione futura. Da un lato ottieni meno bug man mano che li trovi e li risolvi, ma d'altro canto prepari il terreno per futuri bug.

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

Questo mi sembra una sorta di buon gusto per il codice, che puoi sviluppare con la pratica e la revisione e la lettura di persone con problemi simili.

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

Se intendo: "zero bug durante la scrittura del codice" - > è un obiettivo bello ma piuttosto impossibile.

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

Tutto ciò che serve è: qualità del codice incredibilmente alta e copertura del 100% quasi al test (test unitari + test di accettazione + test di integrazione).

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

Prima di tutto hai bisogno di un capo che sia realmente interessato all'alta qualità e che sia disposto a pagarlo.

Soluzione del programmatore:

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

Soluzione utente:

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

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

Accoppia con un altro ingegnere. Scrivi un test non funzionante. È necessario che ogni personaggio che si digita sia necessario per superare il test di sicurezza. Riforma il tuo codice per renderlo più semplice. Scrivi un altro test non funzionante, e così via.