Se i programmatori esperti effettivamente usano mai i debugger e, in tal caso, in quali circostanze. Anche se nella risposta a questa domanda ho detto "mesi" fa probabilmente intendevo "anni" - non uso davvero un debugger. Quindi la mia domanda specifica è in quali circostanze, come programmatore esperto, dovresti usare un debugger?
Direi che non usare un debugger è un segno di inesperienza. Passare attraverso il codice riga per riga è il modo migliore per tracciare il flusso di esecuzione.
Uso spesso il debugger, perché lavoro su un grande sistema e quindi faccio schifo. link
Indipendentemente dal fatto che il tuo codice sia breve e di frequente lettura, c'è sempre la possibilità che abbia dei bug. link
Errare è umano e non si può mai dimostrare che un programma sia corretto, quindi perché non utilizzare strumenti come debugger / test automatici per aiutare noi stessi in questa difficile attività?
Se il codice è abbastanza breve, saranno necessari semplici test. Inoltre, se è breve e conosci la natura del bug, la lettura del codice può essere sufficiente. Tuttavia, una volta che la base di codice è grande, coinvolge più lingue mescolate insieme, più 3 livelli, allora devi semplicemente avere una buona copertura di test su molti livelli più un ottimo debugger, altrimenti perderai un sacco di tempo.
Quindi, quando non ho bisogno di un debugger?
Non sono il programmatore più intelligente, né il più esperto, ma a volte non ho bisogno di usare il debugger. Ecco quando:
Quando faccio molto affidamento su un debugger?
FileNotFoundException . Si noti che "debugger" può riferirsi a più di uno strumento. Uso debugger di Visual Studio, debugger SQL (principalmente per proc stored) e SQL profiler (per capire quale SP viene chiamato). Avrei bisogno di strumenti di questo calibro stavo scrivendo un veloce script Python sysadmin-ish? No. Se avessi creato il mio piccolo strumento basato sulla GUI? Dipende. Se è. Net WinForms - probabilmente no. Se è WPF - sì.
Che cosa definisce comunque un programmatore "reale"? Uno che è veloce? esperto? È bravo negli algoritmi? Scrive buona documentazione? Proprio quando uno si laurea in questo nuovo titolo? Quando si attraversa la linea magica?
Direi che un programmatore che non si è sporcato le mani in uno sforzo di oltre 100 anni uomo non ha avuto la possibilità di essere umiliato dalla complessità e dai propri limiti (oltre che frustrato dalla qualità del codice) .
Personalmente, provo a usare il miglior debugger a mia disposizione e tendo ad usarlo spesso. Se un'attività è abbastanza semplice e non richiede un debugger, non la uso poi. Non ci vuole troppo tempo per capire se ne ho bisogno o no.
...
Ora, in teoria, potevo leggere la base del codice per così tanto tempo che avrei capito. Tuttavia, l'approccio pratico funziona meglio, inoltre spesso desidero riscrivere quello stupido codice che sto vedendo. Sfortunatamente ci vorrebbero più di 10 anni per ripulire il codice base in cui mi trovo. Quindi, usare il debugger è un ovvio primo passo. Solo quando scoprirò quale di queste 5 milioni di linee di codice sta funzionando, dovrei scansionare il file su e giù per cercare di capire cosa sta facendo quella classe.
"Non mi piacciono i debugger, mai, probabilmente non lo faranno mai." - Linus Torvalds
D'altra parte, non ha un account Stack Overflow, quindi non sono sicuro che tu sia interessato alla sua opinione:)
So my specific answerable question is under which circumstances would you, as an experienced programmer, use a debugger?
Modifica
Ho avuto la fortuna / sfortuna di non sapere come usare un debugger nel mio percorso di programmazione. Così in passato sono stato costretto a eseguire il debug senza un debugger. Tuttavia dopo aver imparato a usare un debugger - > Sono diventato 100x più produttivo nel trovare bug.
Per dare una prospettiva leggermente diversa dalle risposte attuali; Come programmatore di software embedded che lavora su sistemi che spesso hanno un componente in tempo reale, utilizzo raramente un debugger.
Ogni tanto un debugger può essere uno strumento straordinario e ogni volta che sono in grado di creare ed eseguire codice su un desktop, utilizzerei sempre un debugger.
Sul chip, con vincoli in tempo reale, vi è un pesante onere associato al tentativo di utilizzare un debugger. Non appena interrompi l'esecuzione, è probabile che tu possa turbare, forse fatalmente, i tempi del resto del sistema. Generalmente su chip, printf in codice non critico e IO waggling in codice time-critical è lo strumento migliore e in realtà più semplice. Non è buono come un debugger, ma è molto più economico lavorare con un sistema reale.
Penso che i programmatori esperti utilizzino quasi esclusivamente i debugger, quando sono necessari. Quale modo migliore per rintracciare un bug piuttosto che seguire effettivamente l'esecuzione del codice ...
Sei sotto l'ipotesi che gli Skeets del mondo non commettano errori o semplicemente sappiano tutto? Tutti tranne i programmi più banali si comportano in modi imprevisti in alcune circostanze. È un dato di fatto che i problemi dovranno essere esaminati. Quindi le scelte sono usare le dichiarazioni di stampa, ad un'estremità dello spettro, oppure esaminare ciò che è successo, post mortem, o guardare nel mezzo mentre il codice viene eseguito e capire cosa sta succedendo.
Forse un modo migliore di pensarci è che i programmatori esperti sanno quando usare un debugger. Nel codice con poche dipendenze guardando una traccia dello stack è probabilmente sufficiente per capire cosa c'è di sbagliato. Ma ci sono scenari complicati in cui il tuo codice funziona con un altro codice, e hai bisogno di un debugger per esaminare le cose che non hai scritto.
No, e ho programmato per oltre 10 anni. Prima, quando programmavo in c / c ++. Ora programma in Java. La verità è che se si esegue correttamente la registrazione, si otterrà una traccia dello stack, sufficiente per la maggior parte degli sviluppatori esperti. Inoltre, se stai scrivendo (buoni) test unitari e test funzionali, questo elimina un'intera classe di bug.
A chi importa? Quello che voglio sapere è che usare un debugger mi impedirà di essere un programmatore migliore nel lungo periodo? Forse i debugger erano di qualità inferiore quando iniziarono molti sviluppatori esperti, quindi erano un ostacolo. È una stampella che impedisce una comprensione più profonda?
Alcuni programmatori, probabilmente migliori di tutti noi, hanno trovato la necessità di un debugger e ne hanno compilato uno (non ho idea di chi abbia creato il primo). Sono sicuro che erano più produttivi a causa di ciò. Dubito che la motivazione fosse di consentire ai mortali minori di scrivere codice.
Raramente.
I tuoi metodi dovrebbero essere piccoli / abbastanza semplici da essere compilati e gestiti dalla tua mente, i test unitari dovrebbero coprire le funzionalità. Se trovi un bug, scrivi un test. Eseguilo, risolvilo.
Tendo ad usare il debugger solo quando ho avuto un comportamento inaspettato da un codice non testabile, come il framework ASP.NET.
In Smalltalk, sviluppo quasi interamente nel debugger:
Uso un debugger quando è necessario. Questo non è quotidiano, ma si verifica occasionalmente. A volte è meglio passare attraverso il codice per vedere cosa succede esattamente.
Devo ammettere che uso i debugger sempre meno. Ho sviluppato in Delphi per oltre 10 anni. Scrivo anche stored procedure in PL / SQL. Da un paio di mesi anch'io sono uno sviluppatore PHP.
Uso principalmente il debugger in entrambi questi casi se trovo un pezzo di codice oscuro che è stato scritto anni fa e ho bisogno di modificarlo. A volte aiuta a scoprire il modo esatto in cui un programma funziona se è difficile leggere il codice. In PHP non è quasi mai necessario, ma in Delphi, che è basato su eventi, a volte aiuta quando hai un quadro complesso.
Ma come dici tu, l'uso del debugger è un'eccezione. La maggior parte dei problemi si risolve semplicemente leggendo il codice e correggendo eventuali errori commessi da te (o da qualcun altro).
Ma ciò vale per passare attraverso il codice. Molto spesso utilizzo lo stack di chiamate quando si verifica un'eccezione e occasionalmente inserisco un punto di interruzione da qualche parte per ispezionare una variabile. Ma quasi sempre in un pezzo di codice che richiede comunque un accurato refactoring.
Di tanto in tanto codice senza alcun debugger, ma solo quando costretto a sparare, cioè. legacy embedded gunge su un 8051 o Z80.
IMHO, hai bisogno di un debugger e di accedere a qualsiasi lavoro complesso. Una volta non è un sostituto per l'altro. Un sistema di registrazione non può essere d'aiuto se l'app si trova in un driver, ad esempio, dove l'unica cosa che il codice può fare è interagire con l'hardware e impostare un semaforo.
Un debugger non può aiutare con un errore di sistema in cui le app funzionano correttamente in base al modo in cui le hai scritte, ma il sistema continua a non funzionare a causa di un errore del protocollo di comunicazione intermittente.
Quindi, ho bisogno che il debugger rimuova i bug stupidi, i bug sgargianti e i cockup hardware. Ho bisogno di una buona registrazione per intercettare i bug intermittenti di integrazione del sistema.
Devo avere entrambi - ho bisogno di tutto l'aiuto che posso ottenere!
Uso solo un debugger quando questi passaggi falliscono:
Questi passaggi si occupano del 95% di tutti i casi. Ciò significa che uso raramente un debugger e, quando lo faccio, tende a darmi troppe informazioni e mi impantanano in dettagli non correlati. Ciò è particolarmente vero se si lavora su un sistema multi-threaded in tempo reale.
Le dichiarazioni di registrazione così posizionate in modo giudizioso fanno molta strada.
Potrebbe semplicemente essere che i programmatori con molta esperienza sono gli stessi di vecchi programmatori, e hanno imparato a programmare e formulare le loro abitudini, quando i debugger non erano sempre disponibili e talvolta non erano molto buoni?
Se sei veramente bravo nel debugging di printf (e negli anni ottanta non avevamo molta scelta, ma diventarlo veramente bravo), forse un debugger non aggiunge molto.
È una questione di scelta personale.
Onestamente penso che i debugger siano utili in alcune situazioni in cui aiuta molto a sapere cosa succede nella tua ram in ogni fase dell'esecuzione del tuo programma.
L'utilità principale di un debugger è arrestare un programma senza che il programma sia progettato per arrestarsi: questa funzione è molto importante.
Oltre a queste 2 funzionalità, non penso che un debugger sia realmente necessario; qualsiasi programma complesso che crei dovrebbe avere una sorta di modalità "verbosa", cioè dire tutto ciò che sta facendo con printf o std :: cout, quali scelte ha fatto e molti altri parametri.
Immagina di creare un programma e l'utente ha un problema ad usarlo: come sapere se lo sta usando nel modo in cui è stato progettato per essere usato, o se la cosa di cui si lamenta potrebbe essere un bug?
I debugger sono come lo sterzo elettrico della tua auto: è più comodo averne uno, ma non renderà la tua guida migliore.
Il Progamming riguarda il design e la logica, il modo in cui gli strumenti possono aiutarti a monitorare le cose non ti rende un programmatore migliore.
I debugger aggiuntivi sono utili per le lingue compilate, molto meno per quelle interpretate.
Leggi altre domande sui tag debugging