Il debugging è una perdita di tempo? [duplicare]

Whenever you hit a bug, don't debug. Instead, spend time learning about topics related to the bug from textbooks and work on other projects until one day you can come back to the bug and solve it instantly thanks to your piled up knowledge.

Fai la falsa ipotesi che le persone "scrivano" bug a causa della mancanza di conoscenza. Un sacco di bug sono errori e fanno false supposizioni. E in realtà il debug di per sé è un'esperienza di apprendimento che ti svilupperà come programmatore.

Sì, il debug è utile a causa di:

3: non consegneresti mai un prodotto funzionante se non lo facessi.

Dipende cosa intendi con il debugging. Nel tuo approccio il debug sembra provare solo fino a quando il bug è stato corretto.

Dal mio punto di vista il debugging è un po 'più ampio, cioè riproducendo il bug in uno scenario isolato, valutando la causa del bug, correggendo il bug, testando in uno scenario comune, ecc. Le iterazioni sono possibili;)

Per rispondere alla domanda, il debug (come definito nel paragrafo precedente) non è una perdita di tempo.

Vorrei affrontare l'argomento dall'altra parte: come evitare di creare bug in primo luogo? La qualità deve essere integrata, non attaccata in seguito.
Ad ogni modo, penso che ci sia una ragione molto semplice per non permettere agli insetti di infastidire se li trovi: tendono a peggiorare se lasciati soli.
Succede anche abbastanza spesso che il comportamento dei bug sia qualcosa su cui lo sviluppo futuro si basa su altre funzionalità. Poi quando vai in giro a sistemare quel bug, finisci per rompere altre cose.

In parole semplici:

Mi batte come mai qualcuno può separare il processo di programmazione dal processo di debugging.

Se scrivi programmi perfetti la prima volta che provi, allora sei Neo, il prescelto della trilogia di Matrix, altrimenti scrivere un programma è un processo di scrittura, test e debugging.

Quindi, no, il debugging non è una perdita di tempo, è una necessità nata dal fatto che non puoi semplicemente scrivere un programma perfetto al primo tentativo.

Il debugging e la ricerca di un bug non sono molto intercambiabili.

Il debugging sta attraversando il tuo codice (usando un debugger, eseguendolo durante la stampa di materiale interno, rivedendo il codice ecc.) cercando di trovare la parte del tuo codice che non fa ciò che intendevi fare.

La ricerca è necessaria quando trovi un problema in una "scatola nera" - una parte del codice che non puoi sondare, sia perché fa parte della lingua, o non hai accesso al suo codice sorgente, o semplicemente manchi l'esperienza / conoscenza / tempo per sondare il codice sorgente da solo. Quando assegni a quell'input della scatola nera che ritieni sia corretto e ti fornisce output o effetti collaterali errati, significa che non lo usi correttamente o che ci sia un bug nel componente stesso. In ogni caso, devi cercarlo per risolverlo.

Il debugging non può essere sostituito con la ricerca. I problemi che richiedono il debug di solito sono problemi specifici del tuo codice. Se la tua funzione restituisce 2 invece di 3 , non puoi reindirizzare il bug perché anche se trovi qualcun altro la cui funzione restituisce 2 anziché 3 , probabilmente sarà per motivi diversi. Anche se il tuo bug cade in uno schema più ampio che puoi ricercare, dovrai spesso eseguire prima il debug per trovare il pattern che e, facendo ciò, probabilmente hai già risolto il bug .

La ricerca non può essere sostituita con il debug. Se trovi una scatola nera del genere, non ti limiterai a inserirla casualmente fino a quando non riuscirai a farlo funzionare. Dal momento che il problema è con qualcosa di esterno, puoi effettivamente cercarlo. Se una funzione dalla libreria esterna restituisce 2 invece di 3 , e trovi qualcun altro su Internet che ha lo stesso problema, probabilmente è dello stesso motivo, dal momento che entrambi usi la stessa funzione.

Il debugging e la ricerca di un bug non sono molto intercambiabili. Quale approccio dovresti prendere (a volte avrai bisogno di entrambi!) Dipende dal bug in questione, non da una regola generale decisa in anticipo.

I tuoi clienti apprezzeranno molto se segnalano un bug critico e prendi l'approccio di lasciarlo semplicemente seduto lì fino a quando improvvisamente una luce si accende nella tua testa e arrivi alla realizzazione di ciò che lo ha causato esattamente diversi mesi dopo senza aver mai fatto sforzi per analizzare realmente il problema ...
Il debugging non è solo lettura del codice sorgente senza mente e sperando di individuare l'errore. Se l'errore fosse stato così ovvio, non avrebbe dovuto mai essere messo in produzione in primo luogo.

Tutte le buone risposte qui. Vorrei solo aggiungere che i bug si dividono in due categorie.

Quando scrivi un programma, hai in mente, se non sulla carta, una nozione di ciò che vuoi che faccia: una serie di requisiti.

Quando un programma non riesce a soddisfare i suoi requisiti, chiamiamolo bug di tipo 1. Esempio: stampa dell'output sbagliato.

Quando un programma non riesce a soddisfare qualsiasi possibile requisito, chiamiamolo bug di tipo 2. Esempio: arresto anomalo o interruzione.

In ogni caso, è importante sapere come rimuovere gli errori in quanto è necessario inserirli.

Whenever you hit a bug, don't debug.

Non sono l'autore originale, quindi non lo so per certo, ma non credo che stiano sostenendo che dovresti mai eseguire il debug. Credo che stiano discutendo contro la tendenza a iniziare immediatamente il debug, non appena trovi un bug. A volte sono colpevole di questo, e può essere molto allettante, perché a volte è un modo rapido per trovare il problema.

Tuttavia, il debug non può sostituire una buona comprensione del codice e, in effetti, avere una buona comprensione può aiutarti a risolvere il problema più rapidamente.

L'abilità, che deriva solo dall'esperienza nel provare entrambi, è capire quanto tempo dedicare alla comprensione del codice, senza un debugger, e quando saltare con il debugger e "vedere cosa sta succedendo"

Per me un bug è quando qualcosa non funziona in un modo che mi aspetto. Il che di solito significa che non capisco come funziona qualcosa e nella maggior parte dei casi l'ho visto significa che è solo un segno di qualcosa di più grave che va male da qualche parte più in profondità. Il che significa che devo trovare perché vedo quello che vedo. In alcuni casi il risultato è "Non so nemmeno come funzionasse prima". Il che è positivo: ho appena rilevato un errore grave notando che qualcosa non funziona.

Quindi no, non è una perdita di tempo.

I bug avvengono generalmente a causa di una errata assunzione di come qualcosa funzioni. La maggior parte delle volte, l'assunto sbagliato riguarda il modo in cui funziona il tuo codice. L'algoritmo che ti è venuto in mente per calcolare qualcosa non fa proprio ciò che pensi, specialmente nei casi limite. Prendi un'ipotesi sull'input che in realtà non regge. E così via.

In alcuni casi, l'assunto sbagliato riguarderà qualcosa di esterno. Hai frainteso l'ordine di inizializzazione durante i lavori di costruzione (o forse sei confuso perché funziona in modo diverso nella lingua a cui sei abituato - basta confrontare l'inizializzazione degli oggetti in Java, C # e C ++). Hai pensato che l'operatore modulo non restituisca mai risultati negativi.

In quest'ultimo caso, l'apprendimento di cose aggiuntive può aiutarti, anche se inciampare nel giusto pezzo di conoscenza è un grande colpo di fortuna.

Ma la maggior parte delle volte, la conoscenza aggiuntiva di cui hai bisogno è esattamente ciò che sta facendo il codice che hai scritto. E imparare questo significa studiare il codice, possibilmente guardarlo, e questo è esattamente ciò che è il debug.

È un concetto interessante una volta superata la risposta emotiva fornita da molte di queste risposte.

Immagina che la domanda "non eseguire mai il debug, invece di scrivere un test per riprodurre il problema e risolvere il codice offendente da quello". Questa è la mia comprensione del posto da cui proveniva l'interrogante.

È una buona idea, ma nel mondo pratico, imperfetto perché i bug non provengono spesso da codice scadente, ma dati scadenti (sì, ok, conta ancora come codice scadente perché non gestisce i dati forniti) . È l'input che conta però. Il codice che funziona perché ha ricevuto i dati previsti durante il test è ancora un codice funzionante, ma quando lo si consegna la pura complessità di un sistema dice che otterrete dati molto inaspettati - specialmente in circostanze in cui i dati potrebbero essere corretti, ma alcuni altri dati altrove potrebbe causare un conflitto. questo è il motivo per cui esegui il debug, provi a capire perché il tuo codice "funzionante" non funziona come previsto.

Un'alternativa valida è molto la registrazione, ma se ne inserisci abbastanza, di solito finisci per restringere la causa che ti lascia con un compito di debug ridotto - che richiede ancora un po 'di debug.