I veri programmatori usano i debugger? [chiuso]

Se i programmatori esperti utilizzano effettivamente i debugger e, in tal caso, in quali circostanze. Anche se nella risposta a questa domanda ho detto "mesi" fa probabilmente intendevo "anni" - in realtà non uso un debugger. Quindi la mia specifica domanda di risposta è in quali circostanze, come programmatore esperto, useresti un debugger?

Direi che non usare un debugger è un segno di inesperienza. Scorrere il codice riga per riga è il modo migliore per tracciare il flusso di esecuzione.

Uso spesso il debugger, perché lavoro su un sistema di grandi dimensioni e quindi faccio schifo. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Non importa quanto sia breve e letto frequentemente il tuo codice, ci sarà sempre la possibilità che abbia dei bug. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Errare è umano e non si può mai dimostrare che un programma sia corretto, quindi perché non usare strumenti come debugger / test automatizzati per aiutarci in questa difficile attività?

Se il codice è abbastanza corto, eseguiranno test semplici. Inoltre, se è breve e conosci la natura del bug, la lettura del codice può essere sufficiente. Tuttavia, una volta che la base di codice è ampia, coinvolge diverse lingue mescolate insieme, più 3 livelli, allora devi semplicemente avere una buona copertura del test su molti livelli più un ottimo debugger - altrimenti perderai molto tempo.

Quindi, quando non ho bisogno di un debugger?

Non sono il programmatore più intelligente, né il più esperto, ma comunque, a volte non ho bisogno di usare il debugger. Questo è quando:

• Il codice è mio o ben scritto AND
• È scritto in una lingua leggibile E
• Il progetto complessivo è di piccole dimensioni.

Quando faccio molto affidamento su un debugger?

• Risposta breve: spesso .
• Quando un'applicazione si arresta in modo anomalo. Soprattutto quando viene distribuito. Avere VS2010 installato su quel computer può fare la differenza tra "Errore sconosciuto" e FileNotFoundException.
• Quando una libreria di terze parti si arresta in modo anomalo o si comporta in modo anomalo.
• Quando il codice è scritto male. Soprattutto se lo stesso file è stato toccato da 10 persone diverse negli ultimi 10 anni, 7 dei quali non sono più con l'azienda.
• Quando il progetto è grande
• Quando il codice è piuttosto monolitico.
• Quando sono coinvolti più livelli (GUI, SQL, BL).

Si noti che "debugger" può fare riferimento a più di uno strumento. Uso anche il debugger di Visual Studio, il debugger SQL (principalmente per i proc memorizzati) e il profiler SQL (per capire quale SP viene chiamato). Avrei bisogno di strumenti di questo calibro che stavo scrivendo un veloce script Python di sysadmin? No. Se avessi creato il mio piccolo strumento basato sulla GUI? Dipende. Se è .Net WinForms - probabilmente no. Se è WPF - sì.

Cosa definisce comunque un programmatore "reale"? Uno che è veloce? esperto? È bravo negli algoritmi? Scrive una buona documentazione? Proprio quando si laurea esattamente 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 cerco di utilizzare il miglior debugger disponibile per me e tendo a usarlo spesso. Se un'attività è abbastanza semplice e non richiede un debugger, allora non la utilizzo. Non ci vuole troppo tempo per capire se ne ho bisogno o no.

...

Ora, in teoria, ho potuto leggere la base di codice per così tanto tempo, che avrei capito. Tuttavia, l'approccio pratico funziona meglio, inoltre spesso voglio riscrivere quello stupido codice che sto vedendo. Purtroppo mi occorrerebbero più di 10 anni per ripulire la base di codice in cui mi trovo. Quindi, usare il debugger è un ovvio primo passo. Solo quando scopro quale di 5 milioni di righe di codice sta funzionando, eseguo la scansione del file su e giù per cercare di capire cosa sta facendo quella classe.

"Non mi piacciono i debugger. Mai, probabilmente non lo farò mai." - Linus Torvalds

D'altra parte, non ha un account Stack Overflow, quindi non sono sicuro che tu sia interessato alla sua opinione :)

Quindi la mia specifica domanda di risposta è in quali circostanze , come programmatore esperto, useresti un debugger?

• Quando non riesci a "eseguire il debug" leggendo il tuo codice.
• Quando non sei in grado di prevedere quali valori hanno determinate variabili in un determinato momento.
• Quando il tuo modello mentale del tuo codice non si adatta all'output dato dal tuo codice

Modificare:

Ho avuto la fortuna / la sfortuna di non sapere come usare un debugger nel mio viaggio di programmazione. Quindi in passato sono stato costretto a eseguire il debug senza un debugger. Tuttavia, dopo aver imparato a usare un debugger -> Sono diventato 100 volte più produttivo nella ricerca di bug.

Dare una prospettiva leggermente diversa dalle risposte attuali; Come ingegnere del software incorporato che lavora su sistemi che spesso hanno un componente in tempo reale, uso raramente un debugger.

A volte un debugger può essere uno strumento straordinario e ogni volta che sono in grado di creare ed eseguire il codice su un desktop, utilizzerei sempre un debugger.

Su chip, con vincoli in tempo reale, c'è un pesante onere associato al tentativo di utilizzare un debugger. Non appena si interrompe l'esecuzione, è probabile che si rovini, possibilmente fatalmente, i tempi del resto del sistema. Generalmente su chip, printf in codice non critico e IO in un codice critico nel tempo sono lo strumento migliore e in realtà più semplice. Non è buono come un debugger, ma è molto più economico iniziare a 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 che seguire effettivamente l'esecuzione del codice ...

Sei convinto che gli Skeets of the world non commettano errori o sappiano semplicemente tutto? Tutti tranne i programmi più banali si comportano in modi inaspettati in alcune circostanze. È un dato di fatto che i problemi dovranno essere investigati. Quindi le scelte sono usare le istruzioni di stampa, a un'estremità dello spettro, o guardare esaminare cosa è successo, post mortem, dall'altra, 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 guardare una traccia dello stack è probabilmente sufficiente per capire cosa non va. Ma ci sono scenari complicati in cui il tuo codice funziona con altri codici e hai bisogno di un debugger per guardare le cose che non hai scritto.

Non lo so, e sto programmando da 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 che è 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.

Che importa? Quello che voglio sapere è che l'uso di un debugger mi impedirà di essere un programmatore migliore a lungo termine? Forse i debugger erano di qualità inferiore quando molti sviluppatori esperti hanno iniziato quindi erano un ostacolo. È una stampella che impedisce una comprensione più profonda?

Alcuni programmatori, probabilmente meglio di tutti noi, hanno trovato la necessità di un debugger e ne hanno creato uno (non ho idea di chi abbia creato il primo.). Sono sicuro che sono stati più produttivi di conseguenza. Dubito che la motivazione fosse quella di consentire ai mortali minori di scrivere codice.

Raramente.

I tuoi metodi dovrebbero essere abbastanza piccoli / semplici da essere compilati ed eseguiti dalla tua mente, i test unitari dovrebbero coprire la funzionalità. Se trovi un bug, scrivi un test. Eseguilo, risolvilo.

Tendo a utilizzare il debugger solo quando ho avuto comportamenti imprevisti da codice non verificabile, come il framework ASP.NET.

In Smalltalk, mi sviluppo quasi interamente nel debugger:

1. Scrivi un test che so fallirà.
2. Esegui il test. Quando fallisce, si apre il debugger.
3. Scrivi, nel debugger, il codice necessario per passare il test.
4. Riprendi l'esecuzione.
5. Se ricevo un semaforo verde, vai al passaggio 1 con un nuovo test fallito. Altrimenti, nel debugger scopri cosa ho fatto di sbagliato e risolvilo.

Uso un debugger quando è necessario. Questo non è quotidiano, ma succede occasionalmente. A volte è meglio scorrere il codice per vedere cosa succede esattamente.

Devo ammettere che utilizzo sempre meno i debugger. Sto sviluppando a Delfi da oltre 10 anni. Scrivo anche stored procedure in PL / SQL. Da un paio di mesi sono anche uno sviluppatore di PHP.

Uso principalmente il debugger in uno di questi casi se trovo un codice oscuro che è stato scritto anni fa e devo modificarlo. A volte aiuta a scoprire esattamente come funziona un programma se è difficile leggere il codice. In PHP questo non è quasi mai necessario, ma in Delphi, che è basato sugli eventi, a volte aiuta quando hai un framework complesso.

Ma come dici tu, usare il debugger è un'eccezione. La maggior parte dei problemi viene risolta semplicemente leggendo il codice e correggendo eventuali errori che tu (o qualcun altro) hai commesso.

Ma questo vale per passare attraverso il codice. Uso abbastanza spesso lo stack di chiamate quando si verifica un'eccezione e ogni tanto metto un punto di interruzione da qualche parte per ispezionare una variabile. Ma quasi sempre in un pezzo di codice che necessita comunque di un completo refactoring.

Di tanto in tanto codice senza debugger, ma solo quando sono costretto a sotto minaccia, ad es. gunge incorporato legacy su un 8051 o Z80.

IMHO, è necessario un debugger e accedere a qualsiasi lavoro complesso. Once non è un sostituto dell'altro. Un sistema di registrazione non può essere d'aiuto se l'app inserisce 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ò essere d'aiuto 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 intermittente del protocollo di comunicazione.

Quindi, ho bisogno del debugger per rimuovere gli stupidi bug e i bug hardware. Ho bisogno di una buona registrazione per rilevare bug di integrazione del sistema intermittenti.

Devo avere entrambi - ho bisogno di tutto l'aiuto che posso ottenere!

Uso un debugger solo quando questi passaggi falliscono:

1. Ottieni l'errore riproducibile. Pensare. Questo è spesso tutto ciò che serve.
2. Controllare eventuali tracce e registri dello stack.
3. Aggiungi più registrazione intorno al codice offensivo.

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 impantana in dettagli non correlati. Ciò è particolarmente vero se si lavora su un sistema multi-thread, in tempo reale.

Le dichiarazioni di registrazione posizionate in modo giudizioso fanno molta strada.

Potrebbe essere semplicemente che programmatori molto esperti sono gli stessi di programmatori molto vecchi e hanno imparato a programmare e hanno formato le loro abitudini, quando i debugger non erano sempre disponibili e talvolta non molto buoni?

Se sei davvero bravo nel debugging di printf (e negli anni ottanta, non avevamo molta scelta ma diventare davvero bravo), forse un debugger non aggiunge molto.

È una questione di scelta personale.

Sinceramente penso che i debugger siano utili in certe situazioni in cui aiuta molto a sapere cosa succede sul tuo ram in ogni dato passaggio dell'esecuzione del tuo programma.

L'utilità principale di un debugger è di arrestare un programma senza che il programma sia progettato per arrestarsi: questa funzionalità è piuttosto importante.

A parte queste 2 caratteristiche, non penso che un debugger sia davvero necessario; qualsiasi programma complesso che fai 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 problemi ad usarlo: come sapere se lo sta usando nel modo in cui è stato progettato per essere utilizzato 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 migliorerà la tua guida.

La programmazione riguarda progettazione e logica, il modo in cui gli strumenti possono aiutarti a tracciare le cose non ti rende un programmatore migliore.

Inoltre i debugger sono utili per i linguaggi compilati, tanto meno per quelli interpretati.