Qual è il vantaggio di evitare l'uso di un debugger?

Ciò che sembra indovinare dall'esterno spesso si rivela essere quello che io chiamo "debugging nella tua mente". In un certo senso, è simile alla capacità dei maestri di giocare a scacchi senza guardare una scacchiera.

È di gran lunga la tecnica di debug più efficace che conosca, perché non richiede affatto un debugger. Il tuo cervello esplora più percorsi di codice allo stesso tempo, producendo un migliore turnaround di quello che potresti ottenere con un debugger.

Non ero consapevole di questa tecnica prima di entrare brevemente nel mondo della programmazione competitiva , dove usare un debugger significava perdere preziosi secondi. Dopo circa un anno di gare, ho iniziato a usare questa tecnica quasi esclusivamente come linea di difesa iniziale, seguita da logging di debug, utilizzando un vero debugger seduto al terzo posto lontano. Un utile effetto collaterale di questa pratica è che ho iniziato ad aggiungere nuovi bug a un ritmo più lento, perché "il debugging nella mia mente" non si è fermato mentre scrivevo il nuovo codice.

Naturalmente questo metodo ha i suoi limiti, dovuti principalmente ai limiti della propria mente nel visualizzare più percorsi attraverso il codice. Ho imparato a rispettare questi limiti della mia mente, trasformandomi in un debugger per correggere bug in algoritmi più avanzati.

Più conosco un codice base, meno ho bisogno di un debugger (ma controllerei comunque l'errore segnalato, è un indizio importante in ogni ragionamento).

È uno strumento utile per comprendere alcuni comportamenti dinamici di piccola o media complessità, ma spesso scopro che mi concentra sui dettagli invece che su un'immagine più ampia. E dopo un po ', ecco i problemi: in interazioni di ambito più ampio il cui comportamento dinamico tende ad essere più facilmente comprensibile con altri strumenti (registrazione di input e output ai limiti del modulo per esempio).

Potrebbero non essere dei cattivi programmatori, ma probabilmente sono strumenti di risoluzione dei problemi terribilmente inefficienti.

Tendo a seguire il consiglio di Debug: le 9 regole indispensabili per trovare anche i problemi software e hardware più elusivi (David Agans), e questo cade esattamente sotto la guida di "Smetti di pensare e guardare"

Qualsiasi lavoro richiede l'utilizzo degli strumenti giusti nel modo giusto. Se hai un debugger allora usalo per vedere cosa sta realmente accadendo. La maggior parte dei bug sono causati da ipotesi.

Ho lavorato con sviluppatori che si rifiutano di usare i debugger perché lo sapevano meglio. La classica risposta che ho ricevuto una volta è stata "l'incidente non è stato causato da me, ho passato tutto il giorno a ispezionare il codice [dove si stava bloccando] e non c'è niente di sbagliato". (Che dire di quel valore nullo che è stato letto dal db?) Il boss sembrava pensare che fosse un'ottima risposta, ma il cliente no.

Sono uscito da quella squadra il più velocemente possibile. Il loro scopo era quello di accarezzare il lavoro e creare un semplice problema di 10 minuti in un problema che dura tutto il giorno.

La tua migliore guida alla pratica del debugging è il libro di Steve McConnel Codice completo . Il capitolo 23 tratta il debug in dettaglio e ne distillerò alcuni punti.

1. Capire il problema è importante, e l'uso del debugger non è un sostituto per questo.
2. Indovinare è un cattivo approccio al debug. Se i tuoi colleghi stanno davvero usando delle congetture, piuttosto che pensare al problema, allora stanno facendo un brutto lavoro. Guesswork significa attaccare dichiarazioni di stampa casuali nel codice e sperare di trovare qualcosa di utile.
3. Se i tuoi colleghi non sanno davvero come usare un debugger (piuttosto che scegliere di non usarne uno) allora sì, sono incompetenti, proprio come qualcuno che non conosce la sintassi della lingua che dovrebbero essere utilizzando.

Difficile da dire. Il debugging indovinando potrebbe funzionare se hai già un'idea su quale sia il bug (valore errato passato a una funzione di libreria, eventualmente SQL non valido, ecc.). Ammetto che lo faccio a volte quando l'errore stesso sembra piccolo o ovvio, come "buffer dei caratteri troppo piccolo" - la traccia dello stack mi mostra la riga che ha fallito e non ho bisogno di un debugger per risolvere quello.

Fare questo tutto il tempo può essere controproducente e se le prime "ipotesi" non riescono, indovinare è probabilmente la strategia sbagliata per la risoluzione dei problemi e un vero debugger dovrebbe essere chiamato. Normalmente, io d dire che non c'è assolutamente niente di sbagliato nell'usare il debugger.

Detto questo, ho lavorato con strumenti e ambienti in cui il debugger era così difficile da funzionare correttamente, o così minimo e inutile che spesso l'ipotesi era un approccio migliore. Ho lavorato con alcuni strumenti proprietari che non avevano nemmeno debugger adeguati. Suppongo sia possibile che se una persona lavorasse in tali ambienti troppo a lungo, alla fine perderebbe la sua fiducia nei debuttanti e farebbe affidamento sull'approccio indovinatore.

Sono sorpreso che la discussione su questo argomento non abbia menzionato "test unitario".

Poiché eseguo lo sviluppo basato su test, non trascorro molto tempo nel debugger. 10 anni fa, passavo diligentemente al debugger:

1. Dopo aver scritto una parte di codice per assicurarti che funzioni e
2. Quando ho ricevuto una segnalazione di errore per provare a diagnosticare il problema

Quello che ho trovato dopo 10 anni di sviluppo guidato dai test è che sono molto più produttivo come programmatore se:

1. Scrivo i test di unità prima scrivo il codice per assicurarmi di averlo scritto correttamente
2. Scrivo i test delle unità immediatamente dopo aver ricevuto una segnalazione di errore per tentare di duplicare e analizzare il problema.

Consentire al computer di scorrere il codice e convalidare il risultato è migliaia di volte più veloce di quanto io possa pensare o eseguire il codice per convalidare mentalmente i risultati e non commettere errori.

Di tanto in tanto devo ancora entrare nel debugger, e sono ancora impegnato a analizzare mentalmente il codice ... ma solo di rado, e soprattutto per codice molto complicato.

Personalmente, provo a minimizzare l'uso di un debugger da:

• utilizzando checker statici e opzioni del compilatore simili che suggeriscono possibili fonti di bug analizzando il codice
• scrivere il codice con alcuni effetti collaterali il più possibile, con lo stile più funzionale possibile, eliminando lo stato mutevole dove possibile
• scrivendo unit test con la minima granularità ragionevole
• non ingoiare le eccezioni

Naturalmente, tutti fanno errori, quindi anche quando si compongono i programmi in questo modo, se un test fallisce, io uso il debugger per ispezionare un valore di un'espressione intermedia. Ma aderendo ai suddetti principi, il difetto è più facile da localizzare e il debugging non significa un processo doloroso e indeterministico.

Usa il debugger quando possibile. Il debugger o semplicemente inchioderà il problema (oh guarda, non abbiamo controllato questo valore), o forniamo una grande quantità di contesto che è utile quando si analizza il codice pertinente (wow, lo stack è completamente incasinato, lo farò si tratta di un problema di buffer overflow).

Il debugging è uno strumento molto utile per controllare lo stato degli oggetti e delle variabili nel codice in fase di esecuzione.

Come accennato in precedenza nelle risposte sopra, il debugging è estremamente utile, ma ci sono alcuni casi in cui è limitato.

Secondo la mia esperienza, trovo che usare il debugger sia molto utile perché aiuta a rivelare le false ipotesi che stavo facendo sullo stato del mio codice. Alcune persone non sono così astute nel leggere il codice per trovare un bug, quindi il debugging può aiutare a svelare false ipotesi che tu o un altro sviluppatore avete fatto sullo stato del codice.

Forse ti aspetti che un parametro non sarà mai nullo se passato a un metodo, quindi non controllerai mai quel caso e prosegui nel metodo come se quel parametro non fosse mai nullo. La realtà è che il parametro sarà finito per essere nullo ad un certo punto, anche se si imposta come pre-condizione al metodo che il parametro non dovrebbe mai essere nullo. Accadrà sempre.

A differenza dell'utilità dei debugger negli esempi sopra citati, trovo che sia difficile e in qualche modo non utile da usare quando è coinvolto il multi-threading (cioè, concorrenza, elaborazione asincrona). Può essere d'aiuto, ma è facile perdere l'orientamento nella nebbia multi-thread quando i punti di interruzione del debugger vengono colpiti in un thread nel punto A e in un thread completamente separato nel punto B. Lo sviluppatore è costretto a premere il nuovo punto di interruzione " processo di pensiero "in cima allo" stack "del suo cervello e orientarsi al codice nel punto del nuovo breakpoint. Dopo che la rilevanza del punto di interruzione B diminuisce, lo sviluppatore torna al primo punto di interruzione e deve ricordare a cosa stava guardando prima del trigger del breakpoint B. So che questa potrebbe essere una spiegazione confusa, ma il mio punto in questo paragrafo è che il debugging in cui viene utilizzata la concorrenza può essere molto ADD (Disturbo da deficit di attenzione), quindi potrebbe essere più difficile rimanere produttivi nel tuo schema di pensiero di debug.

Inoltre, l'imprevedibilità del codice concorrente può ulteriormente distrarre lo sviluppatore nel debug del codice concorrente.

In conclusione, secondo la mia onesta opinione:

• Debug quando viene usata la concorrenza = accresciuta la tendenza a perdere il focus del "debugging pattern di pensiero"

e

• in qualsiasi momento = maggiore produttività di debug b / c la tua attenzione non viene interrotta da interruzioni impreviste (impreviste dovute alle condizioni della gara).

Penso che siano un po 'troppo hardcore. Personalmente quando incappo in un bug, ricontrollo il codice, cerco di rintracciarlo nella mia mente dalla logica del programma, perché a volte questo mi aiuta a scoprire altri problemi o effetti collaterali più semplici del semplice uso del depuratore e del bug che si manifesta quando si manifesta .

Anche se penso di averlo risolto, di solito eseguo il debug per assicurarmi di avere ragione. Quando il problema è un po 'più complesso, credo che il debug sia assolutamente essenziale.

Inoltre ... solo la mia opinione, ma non ci sono scuse per non prendere un vantaggio decente dagli strumenti che un IDE moderno può portare sul tavolo. Se ti aiuta a completare il tuo lavoro più velocemente e in modo più affidabile, dovresti usarlo.

Odio generalizzare, ma molti programmatori che ho incontrato pensano che ci sia solo un modo per risolvere un problema (a modo loro). È facile presumere che ogni possibile test sia stato pensato. Una prospettiva diversa può essere molto preziosa.

La programmazione per tentativi ed errori può generare nuovi fantastici approcci e catturare cose che altri hanno mancato.

Il lato negativo, in genere richiede molto più tempo.

Ehm, dipende dalla persona. Personalmente, non uso molto i debugger. Quando programmo i micro controller, in pratica utilizzo i LED o scrivendo dati su EEPROM per "eseguire il debug" del codice su di esso. Non uso JTAG.

Quando programmo software per PC o server, tendo ad usare la registrazione e un sacco di output della console. Per i linguaggi in stile C, utilizzo le direttive del preprocessore e in Java ho usato i livelli di registro.

Dato che non uso i debugger, diresti che sto facendo qualcosa di sbagliato? Sono i lavori degli editori, per mostrarmi dove ho errori sintattici, e quando c'è un errore logico, devo solo eseguire i test.

C'è una differenza tra non aver bisogno di usare un debugger e non sapere come (o rifiutare di) usare un debugger. Il debugger è solo uno dei tanti strumenti da usare per rintracciare e correggere bug. Ho lavorato con sviluppatori che riescono a risolverlo nella mente e altri che pensano di poter fare.

Il miglior mix è scrivere il tuo codice in modo che sia facile testare tramite unit test e registrare gli errori. Quindi speri che non sia necessario consultare i registri o utilizzare il debugger. È un po 'come acquistare un'assicurazione. Spero che non abbia mai bisogno di usarlo, ma una volta che si è imbattuto in un bug che non può essere risolto ricontrollando il codice, è troppo tardi per aggiungere la corretta gestione degli errori / logging, unit test o imparare a usare un debugger.

Diversi strumenti / piattaforme favoriscono diverse tecniche di debug (debugger, logging, unit test, ecc.) Finché gli sviluppatori hanno familiarità con alcune delle tecniche per la loro piattaforma / strumento, oltre a ricontrollare il codice, quindi potrebbero essere uno sviluppatore esperto, ma se hanno solo un trucco quando si tratta di eseguire il debug, alla fine si imbatteranno in un bug che non riescono a trovare o correggere.

Molte risposte, ma nessuna menzione su Heisenbug ?!?!

Heisenbugs occur because common attempts to debug a program, such as inserting output statements or running it in a debugger, usually modify the code, change the memory addresses of variables and the timing of its execution.

Uso il debugger, solo nel peggiore dei casi (per i bug difficili da trovare). Inoltre, come da best practice di molti sviluppatori / tester acclamati, è bene testare a fondo il codice. In questo modo, puoi coprire la maggior parte dei problemi e quindi non ci sarebbe bisogno di usare il debugger.

Ho letto un argomento contro il debugging del debugging qui di recente (o era StackOverflow?). Dovresti avere casi di test contro il tuo codice. Se passano i test, probabilmente il debugging non eserciterà il bug (supposizione: eseguirai il debug con dati simili ai dati del test).

D'altra parte, la registrazione è obbligatoria. Se si passano i test e si distribuiscono in produzione, è possibile che si sia verificato un errore. La prova del bug proviene da qualcosa che è accaduto in passato. Ad esempio qualcuno dice: "Come ci è entrato?" Se non hai buoni registri, non troverai mai la causa. Anche un debugger può essere inutile a quel punto perché non si sa quale sia l'aspetto dei dati che ha effettivamente esercitato il bug. Devi essere in grado di eseguire il debug dell'applicazione dai log.

Sfortunatamente, sto parafrasando un bel po ', e forse sto rendendo l'argomento originale un disservizio. In particolare, la posizione di "Esistono importanti ausili di debugging per spendere tempo di sviluppo a supporto" potrebbe essere ortogonale all'importanza dei debugger. Ma la parte relativa alla difficoltà di impostare lo stato del sistema in una configurazione che rende il debug utile per trovare i bug mi ha colpito come qualcosa su cui riflettere.

Con buoni test unitari ed eccezioni che ti forniscono il backtrace, raramente devi usare un debugger.

L'ultima volta che ho usato un debug è stato quando ho ottenuto un file core in qualche applicazione legacy.

Am I being a "debbuger minion" or are these guys being "too hardcore"?

Nessuno dei due. Sono solo persone a cui piace rendere la vita più difficile di quanto dovrebbe essere.

Il debug è solo uno strumento che un buon sviluppatore dovrebbe usare con competenza.

Certamente a volte puoi sapere a memoria dove si trova il bug se conosci il codice base. Ma puoi anche perdere un giorno intero o una settimana per trovare un fastidioso bug semplicemente osservando il codice.

Nelle lingue digitate dinamicamente senza alcun tipo di debug (anche se si tratta solo di scaricare i valori nella console) a volte diventa impossibile.

Quindi, per rispondere alla tua domanda, forse sono dei brillanti programmatori, ma le loro capacità di risoluzione dei problemi e la loro competenza nella caccia ai bug sono pessimi.

Dipende dalla portata di un problema. Se il programma è piccolo e le cose sono ben divise, probabilmente puoi capirlo guardando. Se il programma è di 4,5 milioni di linee di codice sviluppate da un team di oltre 100 persone nel corso di diversi anni, alcuni errori saranno impossibili da individuare.

Quello in questione in detto programma (in C) era una sovrascrittura di memoria. Il debugger con un breakpoint di memoria ha identificato la riga di codice incriminata non appena è comparso il bug. Ma in questo caso non c'è modo che qualcuno possa aver letto e conservato tutti i 4,5 milioni di righe di codice per identificare il punto in cui qualcuno ha scritto oltre il loro array (in più avrebbero dovuto conoscere il layout di runtime della memoria per lo stato del programma gigantesco circa 10 minuti in una lunga serie di input per arrivare a quel punto).

Essere punto: in piccoli programmi o cose che sono altamente modularizzate puoi andare via senza un debugger. Se il programma è veramente grande e complesso, il debugger può farti risparmiare un sacco di tempo. Come altri hanno già detto, è uno strumento, e ha le sue situazioni in cui eccelle sopra qualsiasi altro metodo, e altre in cui non è la scelta migliore.

Se il bug si verifica nel computer di un cliente, o in un computer che il suo ambiente è molto diverso dal tuo, configurare un debugger / debugger remoto è complicato. Quindi, per la fredda giornata in cui ricevi un bug dal campo, la risposta di "ma ... non ho un debugger" non aiuta. Pertanto, è necessario sviluppare un set di abilità di risoluzione dei problemi e trovare il bug solo attraverso la comprensione del codice e dei file di registro.

Che assurdità: "I veri programmatori non hanno bisogno di debugger". Potrei anche dire che un vero programmatore non ha bisogno di alcun IDE, dammi solo un blocco note e una matita opaca. Il debugger è uno strumento come tutti gli altri che aiuta la produttività.

Inoltre, considera che non tutti quelli che hanno il compito di eseguire il debug del codice hanno familiarità con quel codice in questione. Molti appaltatori del tempo entrano in un ambiente in cui hanno solo un ideale generale che cosa sta succedendo. Possono anche essere fornite una descrizione dettagliata di un ambiente - o una mappa di schemi di 20 anni e guida a convenzioni di denominazione arcane (prova a capire la differenza tra la tabella X1234 e la tabella X4312 con i campi F1, F2 e F3 [sì, spazzatura come questa esiste] quando sei nuovo), ma molte volte quella descrizione è sbagliata; altrimenti, perché c'è un errore "misterioso".

Come qualcuno di nuovo in un ambiente, puoi passare ore o giorni a mappare e a "conoscere" un ampio database per un'area problematica che potresti correggere e quindi non aver più bisogno di guardare di nuovo. Questo è un enorme spreco di tempo e denaro. Se si ha accesso al debugger, si guarda cosa sta succedendo, si corregge e se ne va in pochi minuti. Tutto questo "non hai bisogno di debugger" è solo un eufemismo.