Come eseguire il debug del codice nel modo più efficace? [chiuso]

La mentalità e latteggiamento verso il debugging è forse il parte più importante, perché determina quanto efficacemente risolverai lerrore e cosa imparerai da esso, semmai.

I classici sullo sviluppo di software come The Pragmatic Programmer e Code Complete sostengono fondamentalmente lo stesso approccio: ogni errore è unopportunità per imparare, quasi sempre su te stesso (perché solo i principianti incolpano prima il compilatore / computer).

Quindi trattalo come un mistero che sarà interessante da risolvere. E risolvere quel mistero dovrebbe essere fatto sistematicamente, esprimendo le nostre ipotesi (a noi stessi o agli altri) e quindi testando le nostre ipotesi, una per una se necessario, utilizzando tutti gli strumenti a nostra disposizione, in particolare debugger e framework di test automatizzati. Quindi, dopo che il mistero è stato risolto, puoi fare ancora di meglio cercando in tutto il tuo codice errori simili che potresti aver fatto; e scrivere un test automatico per assicurarsi che lerrore non si verifichi di nuovo inconsapevolmente.

Unultima nota: preferisco chiamare gli errori “errori” e non “bug” – Dijkstra rimproverò i suoi colleghi di usare questultimo termine perché è disonesto, sostenendo lidea che le fate degli insetti perniciosi e volubili abbiano piantato bug nei nostri programmi mentre non stavamo cercando, invece di essere lì a causa del nostro (sciatto) pensiero: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Potremmo, ad esempio, iniziare a ripulire la nostra lingua non chiamando più un bug un bug ma definendolo un errore. È molto più onesto perché mette esattamente la colpa a cui appartiene, vale a dire. con il programmatore che ha commesso lerrore. La metafora animistica del bug che si è intrufolato maliziosamente mentre il programmatore non stava guardando è intellettualmente disonesta in quanto nasconde che lerrore è la creazione del programmatore. La cosa bella di questo semplice cambio di vocabolario è che ha un effetto così profondo : mentre prima un programma con un solo bug era “quasi corretto”, dopo un programma con un errore è semplicemente “sbagliato” (perché in errore).

Commenti

• In realtà mi piace il termine " errore " piuttosto che " bug ", non perché dà la colpa a " il programmatore chi ha commesso lerrore ", ma perché rende chiaro che potrebbe non essere stato il programmatore responsabile. Per me, " bug " implica un errore nel codice; mentre " erro r " implica un errore da qualche parte . Forse nel codice, forse nella configurazione dellambiente, forse nei requisiti. Mi fa impazzire quando il mio capo ha un " elenco di bug " in cui metà dei problemi sono modifiche ai requisiti. Chiamalo un elenco di attività, ferchrissakes!
• +1 per " ogni errore è unopportunità per imparare, quasi sempre su te stesso (perché solo i principianti incolpano il compilatore / prima il computer) "
• Sei a conoscenza della cronologia del termine " bug ", giusto? Voglio dire, come usato nello sviluppo del software. Ovviamente, ' oggi non abbiamo questo problema, ma un bug è effettivamente volato nellhardware di un computer senza essere notato dal programmatore e ha causato un problema.Per timore che qualcuno pensi di correggermi, so che Edison ha usato questo termine molto prima dellincidente della falena, motivo per cui ho usato la parola ' history ', non ' origin '. Vedi computerworld.com/article/2515435/app-development/… e en.wikipedia.org/wiki/Software_bug#Etymology
• @threed Ovviamente. Ma per un po di tempo, gli insetti non hanno causato la maggior parte degli errori del software.

1. Scrivi test. Il test non è solo ottimo per prevenire i bug (nella mia esperienza, TDD fatto bene elimina quasi tutti i bug banali e stupidi), ma aiuta anche molto nel debugging. I test costringono il tuo progetto ad essere piuttosto modulare, il che rende molto più facile isolare e replicare il problema. Inoltre, controlli lambiente, quindi ci saranno molte meno sorprese. Inoltre, una volta che si ottiene un test case fallimentare, si può essere ragionevolmente sicuri di aver individuato il motivo reale del comportamento che ti dà fastidio.

2. Impara a usare un debugger. print le istruzioni possono funzionare abbastanza bene a un certo livello, ma un debugger la maggior parte delle volte è molto utile (e una volta sai come usarlo, è molto più comodo delle print istruzioni).

3. Parla di qualcuno del tuo problema, anche se “è solo un paperella di gomma . Costringere te stesso a esprimere a parole il problema su cui stai lavorando fa davvero miracoli.

4. Concediti un limite di tempo. Se ad esempio dopo 45 minuti senti che non stai andando da nessuna parte, passa ad altre attività per un po di tempo. Quando torni al tuo bug, spero che sarai in grado di vedere altre possibili soluzioni che non avresti “preso in considerazione prima.

Commenti

• +1 per " Costringere te stesso a esprimere a parole il problema su cui stai lavorando fa davvero miracoli. "
• E per aggiungere a (1), quasi tutti i bug che vedi nel codice implicano che ' cè un bug – o almeno unomissione – nella suite di test. Risolvi entrambi allo stesso tempo e non solo dimostri che ' hai risolto il problema in questione, ma ' sei al sicuro. reintrodotto.

Mi piacciono la maggior parte delle altre risposte, ma ecco alcuni suggerimenti su cosa fare PRIMA di fare qualsiasi cosa. Ti farà risparmiare un sacco di tempo.

1. Determina se cè davvero un bug. Un bug è SEMPRE una differenza tra il comportamento e i requisiti del sistema; il tester dovrebbe essere in grado di articolare il comportamento atteso e quello effettivo. Se non è in grado di fornire supporto per il comportamento previsto, non ci sono requisiti e non ci sono bug, solo lopinione di qualcuno. Rimandalo indietro.

2. Considera la possibilità che il comportamento previsto è sbagliato. Ciò potrebbe essere dovuto a unerrata interpretazione del requisito. Potrebbe anche essere dovuto a un difetto nel requisito stesso (un delta tra un requisito dettagliato e un requisito aziendale). Puoi anche rispedirli.

3. Isola il problema. Solo lesperienza ti insegnerà il modo più veloce per farlo: alcune persone possono quasi farlo con il loro istinto. Un approccio di base è variare una cosa mentre mantenendo tutte le altre cose costanti (il problema si verifica su altri ambienti? con altri browser? in una diversa regione di test? in diversi momenti della giornata?) Un altro approccio è guardare i dump dello stack o i messaggi di errore – a volte puoi dirlo solo dal modo in cuièformattato quale componente del sistema ha generato lerrore originale (es. seèin tedesco puoi bla me quella terza parte con cui lavori a Berlino).

4. Se hai ristretto il campo a due sistemi che collaborano, controlla i messaggi tra i due sistemi tramite monitor del traffico o file di registro e determinare quale sistema si sta comportando secondo le specifiche e quale no. Se nello scenario sono presenti più di due sistemi, è possibile eseguire controlli a coppie e procedere “verso il basso” nello stack dellapplicazione.

5. Il motivo per cui isolare il problema è così critico è che il problema potrebbe non essere dovuto a un difetto nel codice su cui si ha il controllo (ad es. sistemi di terze parti o ambiente) e si desidera che quella parte subentri il più rapidamente possibile. Questo serve sia per risparmiare lavoro che per metterli subito al punto in modo che la risoluzione possa essere raggiunta nel minor tempo possibile. Non vuoi lavorare su un problema per dieci giorni solo per scoprire che è davvero un problema con il servizio web di qualcun altro.

6. Se hai determinato che esiste davvero un difetto ed è davvero nel codice che controlli, puoi isolare ulteriormente il problema cercando lultima build “notoriamente valida” e ispezionando i log di controllo del codice sorgente per le modifiche che potrebbero aver causato il problema. Questo può far risparmiare molto tempo.

7. Se non riesci a capirlo dal controllo del codice sorgente, ora è il momento di collegare il tuo debugger e passare attraverso il codice per immaginarlo È probabile che tu abbia comunque una buona idea del problema.

Una volta che sai dove si trova il bug e puoi pensare a una soluzione, ecco “una buona procedura per risolverlo:

1. Scrivi uno unit test che riproduca il problema e fallisca.

2. Senza modificare lo unit test, fai supera (modificando il codice dellapplicazione).

3. Conserva lo unit test nella tua suite di test per prevenire / rilevare la regressione.

Penso che anche la riproduzione di un bug sia importante. Tutti i casi che riproducono il bug possono essere elencati e quindi puoi assicurarti che la tua correzione del bug copra tutti quei casi.

Cè un ottimo libro che ho letto su questo argomento chiamato Why Programs Fail , che delinea varie strategie per trovare bug che vanno dallapplicazione del metodo scientifico per isolare e risolvere un bug, per delta debugging. Laltra parte interessante di questo libro è che elimina il termine “bug”. Lapproccio di Zeller è:

(1) Un programmatore crea un difetto nel codice. (2) Il difetto causa uninfezione (3) Linfezione si propaga (4) Linfezione causa un errore.

Se vuoi migliorare le tue capacità di debug, consiglio vivamente questo libro.

Nella mia esperienza personale, ho trovato molti bug nella nostra applicazione, ma la gestione ci spinge semplicemente ad andare avanti per ottenere nuove funzionalità. “Ho sentito spesso” Abbiamo trovato questo bug noi stessi e il client non lo ha ancora notato, quindi lascialo finché non lo fa “. Penso che essere reattivi anziché proattivi nella correzione dei bug sia una pessima idea perché quando arriva il momento di mettere effettivamente una correzione, hai altri problemi che devono essere risolti e più la gestione delle funzionalità vuole uscire dalla porta il prima possibile, così ti beccano in un circolo vizioso che può portare a una grande quantità di stress e burn out e, in definitiva, a un sistema pieno di difetti.

La comunicazione è anche un altro fattore quando vengono rilevati bug. Inviare une-mail o documentarla sul bug tracker va benissimo, ma secondo la mia esperienza, altri sviluppatori trovano un bug simile e invece di riutilizzare la soluzione che hai messo per correggere il codice (poiché si sono dimenticati del tutto), aggiungono le loro versioni, quindi hai 5 diverse soluzioni nel tuo codice e di conseguenza sembra più gonfio e confuso. Quindi, quando risolvi un bug, assicurati che alcune persone esaminino la correzione e ti forniscano un feedback nel caso abbiano risolto qualcosa di simile e ha trovato una buona strategia per affrontarlo.

limist ha menzionato il libro,