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

Nel corso della mia carriera, ho notato che alcuni sviluppatori non usano strumenti di debug, ma effettuano controlli a campione su codice errato per capire qual è il problema.

Mentre molte volte essere in grado di trovare rapidamente errori nel codice senza un debugger è una buona abilità da avere, sembra che sia meno produttivo passare molto tempo a cercare problemi quando un debugger trova facilmente piccoli errori come errori di battitura.

È possibile gestire un complesso senza debugger? È consigliabile? Quali benefici si possono ottenere usando il " debugging psichico "?

Ciò che sembra indovinare dall'esterno risulta spesso essere ciò che chiamo "debug nella tua mente". In un certo senso, questo è simile alla capacità dei nonni di giocare a scacchi senza guardare una scacchiera.

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

Non ero a conoscenza di questa tecnica prima di entrare brevemente nel mondo della programmazione competitiva , dove usare un debugger significava perdere secondi preziosi. Dopo circa un anno di competizione, ho iniziato a utilizzare questa tecnica quasi esclusivamente come mia linea di difesa iniziale, seguita dal log di debug, con l'utilizzo di un debugger reale seduto al terzo posto distante. Un utile effetto collaterale di questa pratica è che ho iniziato ad aggiungere nuovi bug a un ritmo più lento, perché il "debug nella mia mente" non si è fermato mentre scrivevo un 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, passando a un debugger per correggere bug in algoritmi più avanzati.

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

È uno strumento eccellente per comprendere alcuni comportamenti dinamici di complessità medio-piccola, ma spesso scopro che mi concentra sui dettagli anziché sull'immagine più grande. E dopo un po ', ecco dove si trovano i problemi: nelle interazioni di portata più ampia il cui comportamento dinamico tende ad essere più facilmente comprensibile con altri strumenti (registrazione di input e output ai confini del modulo, ad esempio).

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

Tendo a seguire il consiglio del debug: le 9 regole indispensabili per trovare anche i problemi software e hardware più elusivi (David Agans), e questo rientra 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, usalo per vedere cosa sta realmente accadendo. La maggior parte dei bug è causata da ipotesi.

Ho lavorato con sviluppatori che si rifiutano di utilizzare i debugger perché conoscevano 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 stava andando in crash] e non c'è niente di sbagliato". (Che dire di quel valore nullo che è stato letto dal db?) Il capo sembrava pensare che fosse un'ottima risposta, ma il cliente no.

Ho lasciato quella squadra il più velocemente possibile. Il loro scopo era quello di rendere piumaggio il lavoro e trasformare un semplice problema di 10 minuti in un problema tutto il giorno che sembra occupato.

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

1. Comprendere il problema è importante e l'uso del debugger non può sostituirlo.
2. Indovinare è un cattivo approccio al debug. Se i tuoi colleghi usano davvero le congetture, piuttosto che pensare al problema, stanno facendo un brutto lavoro. Indovinare significa inserire nel codice dichiarazioni di stampa casuali 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 usare.

Difficile da dire. Il debug indovinando potrebbe funzionare se hai già un'idea di cosa sia il bug (valore errato passato a una funzione di libreria, possibilmente SQL non valido, ecc.). Ammetto di farlo a volte quando l'errore stesso sembra piccolo o ovvio, come "buffer di caratteri troppo piccolo" - la traccia dello stack mi mostra la linea che ha fallito e non ho bisogno di un debugger per risolverlo.

Farlo tutto il tempo può essere controproducente e se le prime "ipotesi" falliscono, indovinare è probabilmente la strategia di risoluzione dei problemi sbagliata e dovrebbe essere chiamato un vero debugger. Normalmente, direi che non c'è assolutamente nulla di sbagliato nell'usare il debugger .

Detto questo, ho lavorato con strumenti e ambienti in cui il debugger era così difficile da far funzionare bene, o così minimale e inutile che indovinare era spesso 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 fiducia nei debugger e si affiderebbe esclusivamente all'approccio delle ipotesi.

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

Poiché eseguo uno sviluppo guidato dai test, non passo molto tempo nel debugger. 10 anni fa, eseguivo scrupolosamente il debugger:

1. Dopo aver scritto un pezzo di codice per assicurarsi che abbia funzionato e
2. Quando ho ricevuto una segnalazione di bug per provare a diagnosticare il problema

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

1. Scrivo unit test prima di scrivere il codice per assicurarmi di averlo scritto correttamente
2. Scrivo test unitari immediatamente dopo aver ricevuto una segnalazione di bug per tentare di duplicare e approfondire il problema.

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

Devo ancora passare di tanto in tanto nel debugger e sono ancora impegnato ad analizzare mentalmente il codice ... ma solo raramente, e soprattutto per codice molto complicato.

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

• utilizzando controlli statici e opzioni di compilatore simili che suggeriscono possibili fonti di bug semplicemente analizzando il codice
• scrivere codice con il minor numero possibile di effetti collaterali , nello stile più funzionale possibile, eliminando lo stato mutabile ove possibile
• scrivere test unitari con la minima granularità ragionevole
• non ingoiare eccezioni

Naturalmente, tutti commettono errori, quindi anche quando compongo i programmi in questo modo, se un test fallisce, uso il debugger per ispezionare il valore di un'espressione intermedia. Aderendo ai principi di cui sopra, il difetto è più facile da individuare e il debug non significa un processo doloroso e indeterministico.

Utilizzare il debugger quando possibile. Il debugger risolverà semplicemente il problema (oh guarda, non abbiamo verificato questo valore), o fornirà una grande quantità di contesto che è utile quando si analizza il codice pertinente (wow, lo stack è completamente incasinato, lo farò sia un problema di overflow del buffer).

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

Come precedentemente menzionato nelle risposte sopra, il debug è estremamente utile, ma ci sono alcuni casi in cui è limitato.

Nella mia esperienza, trovo che usare il debugger sia molto utile perché aiuta a rivelare 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 debug può aiutare a rivelare false ipotesi fatte da te o da un altro sviluppatore sullo stato del codice.

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

Contrariamente all'utilità dei debugger negli esempi sopra citati, trovo difficile e in qualche modo non utile usare quando è coinvolto il multi-threading (ovvero concorrenza, elaborazione asincrona). Può essere d'aiuto, ma è facile perdere l'orientamento nella nebbia multi-thread quando i breakpoint del debugger vengono colpiti in un thread nel punto A e in un thread completamente separato nel punto B. Lo sviluppatore è costretto a spingere il nuovo breakpoint " processo di pensiero "in cima alla" pila "del suo cervello e orientarsi verso il codice nel punto del nuovo punto di interruzione. Dopo che la rilevanza del punto di interruzione B diminuisce, lo sviluppatore ritorna al primo punto di interruzione e deve ricordare ciò che stava cercando prima del trigger del punto di interruzione B. So che questa potrebbe essere una spiegazione confusa,

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

In conclusione, a mio onesto parere:

• Debug quando viene utilizzata la concorrenza = maggiore tendenza a perdere la concentrazione del "modello di pensiero di debug"

e

• in qualsiasi altro momento = aumento della produttività del debug b / c la tua attenzione non viene interrotta da punti di interruzione imprevisti (imprevisti a causa delle condizioni di gara).

Penso che siano un po 'troppo hardcore. Personalmente quando mi imbatto in un bug, ricontrollo il codice, provo a rintracciarlo nella mia mente dalla logica del programma, perché ciò a volte mi aiuta a scoprire altri problemi o effetti collaterali più facilmente del semplice utilizzo del debbuger e della correzione del bug in cui si manifesta .

Anche quando penso di averlo inchiodato, 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 trarre 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 esista un solo modo per risolvere un problema (a modo loro). È facile supporre che sia stato pensato ogni possibile test. Una prospettiva diversa può essere molto preziosa.

La programmazione per tentativi ed errori può portare ad alcuni grandi nuovi approcci e catturare cose che altri hanno perso.

Il rovescio della medaglia, di solito richiede molto più tempo.

Ehm, dipende dalla persona. Personalmente, non uso così tanto i debugger. Quando programmo i microcontrollori, sostanzialmente utilizzo i LED o scrivo i dati nelle EEPROM per "eseguire il debug" del codice su di esso. Non uso JTAG.

Quando programma software per PC o server, tendo a utilizzare la registrazione e molti output della console. Per i linguaggi in stile C, utilizzo le direttive del preprocessore e in Java ho usato i livelli di registro.

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

Esiste una differenza tra non dover utilizzare un debugger e non sapere come (o rifiutare di) utilizzare un debugger. Il debugger è solo uno dei tanti strumenti da utilizzare per tracciare e correggere i bug. Ho lavorato con sviluppatori che possono risolverli in testa e altri che pensano di poterlo fare.

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

Diversi strumenti / piattaforme favoriscono diverse tecniche di debug (debugger, logging, unit test, ecc.) Fintanto che uno sviluppatore ha familiarità con alcune delle tecniche per la propria piattaforma / strumento, oltre a ricontrollare il codice, potrebbero essere uno sviluppatore esperto, ma se hanno solo un trucco quando si tratta di debug, alla fine si imbatteranno in un bug che non possono trovare o risolvere.

Molte risposte, ma non una menzione di Heisenbug ?!?!

Gli Heisenbug si verificano perché i tentativi comuni di debug di un programma, come l'inserimento di istruzioni di output o l'esecuzione in un debugger, in genere modificano il codice, cambiano gli indirizzi di memoria delle variabili e i tempi della sua esecuzione.

Uso il debugger, solo nel peggiore dei casi (per bug difficili da trovare). Inoltre, secondo le migliori pratiche di cui molti sviluppatori / tester acclamati hanno parlato, è bene testare a fondo il codice. In questo modo, è possibile coprire la maggior parte dei problemi e quindi non è necessario utilizzare il debugger.

Di recente ho letto un argomento contro il debug del debug (o StackOverflow?). Dovresti avere casi di test contro il tuo codice. Se i test vengono superati, probabilmente il debug non eserciterà il bug (presupposto: eseguirai il debug con dati simili ai dati del test).

D'altra parte, la registrazione è obbligatoria. Se si superano i test e si distribuiscono alla produzione, è possibile riscontrare un bug. L'evidenza del bug proviene da qualcosa che è accaduto in passato. cioè qualcuno dice "Come è potuto entrare?" Se non hai buoni registri, non troverai mai la causa. Anche un debugger potrebbe non essere utile a quel punto perché non sai come apparivano i dati che effettivamente esercitavano il bug. Devi essere in grado di eseguire il debug dell'applicazione dai registri.

Sfortunatamente, sto parafrasando un bel po ', e forse sto facendo dell'argomentazione originale un disservizio. In particolare, la posizione di "Esistono importanti assistenti di debug per dedicare tempo allo sviluppo" potrebbe essere ortogonale all'importanza dei debugger. Ma la parte sulla difficoltà di impostare lo stato del sistema in una configurazione che rende utile il debug per la ricerca di bug mi ha colpito come qualcosa a cui pensare.

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 un'applicazione legacy.

Sono un "seguace debbuger" o questi ragazzi sono "troppo hardcore"?

Nessuno dei due. Sono solo persone a cui piace rendere la loro 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 può essere il bug se conosci la base di codice. Ma puoi anche perdere un intero giorno o settimana per trovare un fastidioso bug semplicemente guardando nel codice.

Nei linguaggi tipizzati dinamicamente senza alcun tipo di debug (anche se si tratta solo di scaricare valori sulla console) a volte diventa impossibile indovinare.

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

Dipende dalla portata di un problema. Se il programma è piccolo e le cose sono ben suddivise, probabilmente puoi capirlo guardando. Se il programma è composto da 4,5 milioni di righe di codice sviluppate da un team di oltre 100 persone nel corso di diversi anni, sarà impossibile individuare alcuni bug.

Quello in questione in detto programma (in C) era una sovrascrittura della memoria. Il debugger con un punto di interruzione della memoria ha identificato la riga di codice offensiva non appena è apparso il bug. Ma in questo caso non è possibile che qualcuno abbia potuto leggere e conservare tutti i 4,5 milioni di righe di codice per identificare il punto in cui qualcuno ha scritto oltre il proprio array (in più avrebbero dovuto conoscere il layout di runtime della memoria per lo stato del gigantesco programma circa 10 minuti in una lunga serie di input per arrivare a quel punto).

Il punto è: in piccoli programmi o cose che sono altamente modularizzati è possibile cavarsela senza debugger. Se il programma è davvero 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 altri in cui non è la scelta migliore.

Se il bug si verifica nel computer di un client o in un computer in cui il suo ambiente è molto diverso dal tuo, la configurazione di un debugger / debugger remoto è scomoda. 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 una serie di abilità per la risoluzione dei problemi e la ricerca del 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 qualsiasi altro che aiuta la produttività.

Inoltre, considera che non tutti i responsabili del codice di debug hanno familiarità con quel codice in questione. Molti appaltatori di tempo entrano in un ambiente in cui hanno solo un ideale generale ciò che sta accadendo. Potrebbe anche essere data loro una descrizione dettagliata di un ambiente - o una mappa dello schema di 20 anni e una guida alle 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ì, immondizia come questa esiste] quando sei nuovo), ma molte volte quella descrizione è sbagliata; altrimenti, perché c'è un errore "misterioso".

Come nuovo utente di un ambiente, puoi passare ore o giorni a mappare e a "conoscere" un database di grandi dimensioni per un'area problematica che potresti risolvere e che non dovrai mai più rivedere. Questo è un enorme spreco di tempo e denaro. Se hai accesso al debugger, vedi cosa sta succedendo, correggilo e sparisci nel giro di pochi minuti. Tutto questo hooey "non hai bisogno di debugger" è solo un gioco d'élite.