L'uso dei debugger ha un effetto sull'efficienza dei programmatori? [duplicare]

Influenza l'efficienza in un modo molto buono. Sento che è usato troppo raramente dagli sviluppatori.

Non solo è utile per il debug ma può anche darti un'idea della profilazione.
Ad esempio, quando lo stepping della linea ti fa sentire "ahh", questa linea ha impiegato un po 'troppo tempo per essere eseguita e hai un'idea di dove sono i colli di bottiglia nella tua app.

Il debug consuma tempo poiché esegui codice un miliardo di volte più lento di quanto faresti in un test unitario. Spesso c'è uno strumento migliore per il lavoro: microbenchmarks, profiler di prestazioni, unit test, registrazione o semplicemente leggendo il codice. Con una suite di test unitari è possibile eseguire dozzine di percorsi di codice in millisecondi, che richiederebbero ore in un debugger.

I raramente eseguo il debug quando riesco a scrivere un test dell'unità . In questo modo, hai un record sotto forma di un test eseguibile di come funziona il codice. Se esegui semplicemente il debug, quella conoscenza è solo nella tua testa finché non la dimentichi.

Quando devi eseguire il debug, i suggerimenti specifici sono di imparare il passaggio sopra / in / ritorno tasti di scelta rapida per il tuo debugger, come controllare le variabili e utilizzare le istruzioni di interruzione condizionale.

Solo la mia opinione, ma ritengo che l'uso regolare e sistematico di un debugger a livello di linea potrebbe essere la singola massima pratica di miglioramento della produttività che un programmatore ha a disposizione. Sia che tu stia saltando dentro e stia cercando di imparare un codice esistente o semplicemente cercando di far funzionare il tuo codice, portalo nel debugger e avvia Stepping.

Sei fortunato, credo, a lavorare in un posto in cui sei incoraggiato a imparare e usare un debugger. Ho visto molti, molti programmatori veterani che non hanno mai imparato a usare uno strumento prezioso.

Desidero davvero che il nostro ultimo sviluppatore abbia usato un debugger. Avevamo un sito PHP con un framework con molte buone funzionalità di debug, ha usato nessuno di loro . Dal momento che il codice era PHP e non c'erano errori del compilatore, apparentemente ha mutilato allegramente il suo codice fino a quando non ha funzionato in fase di esecuzione.

Ogni singola pagina ha generato dozzine di avvertimenti o errori in modalità di debug e se si è preso la briga di leggere l'output di debug o analizzare riga per riga ciò che stava facendo il suo codice, molto di ciò avrebbe potuto essere evitato. Piuttosto che usare un debugger, ha usato il codice manuale per scrivere variabili in un file .log sul server. Ha lasciato quel codice in produzione; i file di registro erano 8 GB quando li ho ricevuti.

Potresti passare più tempo a esaminare il tuo codice, ma impiegherà meno tempo a provare a risolverlo . Scriverò anche il codice migliore e ti aiuterà a capire il tuo codice, rendendoti un programmatore migliore .

Alcuni zeloti là fuori potrebbero affermare che i debugger ti rendono pigro, o che dovresti semplicemente scrivere un unit test per tutto. Per quelli di noi che devono effettivamente fare le cose, un debugger è uno strumento essenziale per risolvere rapidamente il problema / esplorare il codice. Ovviamente la copertura del test è ottima e ti consente di sapere che cosa sta facendo il tuo codice, ma a volte hai solo bisogno di entrare nel vivo e vedere cosa sta succedendo.

L'uso di un debugger va bene quando qualcosa non funziona o quando non si capisce cosa faccia un codice legacy. Usando un debugger quando non fallisce nulla, solo perché non capisci cosa fa il tuo codice (le linee che hai scritto negli ultimi 10 minuti), IMHO è una pessima pratica. In questo caso, potresti migliorare la tua produttività molto più investendo tempo nello scrivere il tuo codice in un modo più leggibile o comprensibile invece del debugging, o scrivendo alcuni test automatici.

L'uso del debugger aumenta indubbiamente la tua efficienza, poiché ti consente di fare cose che sarebbero difficili o impossibili da fare senza. È molto più efficace valutare le espressioni al volo, cambiare le variabili locali ecc. Piuttosto che pre-indovinare ciò che potrebbe interessarti e scrivere le corrispondenti printf dichiarazioni, e setacciare l'output esattamente per quello che vuoi sapere .

Tuttavia potrebbe indicare che ci sono altri problemi - normalmente vorrebbe essere in grado di scrivere codice di routine senza doverlo esaminare attentamente anche una sola volta, poiché è il risultato che conta piuttosto che il dettagli, e che può essere affermato tramite test unitari. Tuttavia, è una questione di preferenze personali. Potresti essere molto più produttivo con il tuo stile esplorativo rispetto al tuo collega con il loro stile basato sui test e viceversa.

I debugger sono solo un altro strumento. Può davvero aiutare la tua comprensione della programmazione quando stai iniziando, e può a volte semplificare i problemi più difficili.

C'è anche una parte logica per risolvere i problemi - molti problemi che coinvolgono il threading o le interazioni dei sistemi possono essere difficili o impossibili da tracciare con un debugger - per coloro che potrebbero aver bisogno di strumenti diversi - lavorare sulle tue capacità di problem solving MAI fa male.

Sai che una cosa che ho imparato nel corso degli anni è che chiunque abbia una competenza specifica pensa di conoscere il 90% di ciò che hanno bisogno di sapere - il problema è che le persone in genere non possono sapere cosa non fanno so (se vedessero qualcosa che non sapevano, sarebbero andati a impararlo!)

Perché lo aggiungo? Bene, ho visto sviluppatori che possono risolvere molti problemi senza un debugger molto più rapidamente di quanto avrebbe dovuto fare per far funzionare il debugger. L'eccessiva dipendenza può rallentare se è la prima cosa che fai ogni volta.

È come imparare sulla tastiera - se un dattilografo iniziale dovesse digitare su una tastiera senza lettere, penserebbe che fosse ovvio che avere le lettere era meglio - ma poi si raggiunge un punto in cui avere le lettere rimosse può fare sei molto più veloce (insegnandoti a non guardare le tue mani), e infine raggiungi il punto in cui è completamente irrilevante se le lettere sono sui tasti o meno.

Nel programmare alcune persone raggiungono quell'ultima fase in cui il debugger ti rallenta, ma probabilmente ci sono più cose in cui il fatto di averle portate via potrebbe aumentare significativamente le loro capacità di analisi - ma la maggior parte delle persone è probabilmente nella prima fase ti manca solo senza.

Al lavoro, l'uso di un debugger aumenta l'efficienza del programmatore. A scuola, puoi risparmiarlo dato che è bello eseguire a secco l'algoritmo del tuo codice di programmazione per ottenere i symantics corretti e desiderati.

Il debugger è uno strumento efficiente e utile per i programmatori. Non puoi evitarlo a livello professionale. È bene che tu impari a usare un debugger per il tuo ambiente di programmazione, poiché questo ti aiuterà enormemente a risparmiare tempo e fatica di programmazione. Quindi usare un debugger è una buona pratica di programmazione al lavoro!

Ovviamente un debugger ha un valore inestimabile per comprendere il tuo codice e quello degli altri sviluppatori. Tuttavia, non appoggiarti! Per gli approcci dal basso verso l'alto, generalmente dovresti cercare di trovare una prova che il tuo codice sta facendo ciò che dovrebbe fare. Il codice multi-thread in genere è difficile da eseguire il debug, soprattutto quando si verificano problemi con deadlock / lifelocks / starvation. Ritengo che sia uno dei motivi principali per cui molti programmatori indisciplinati trovano così difficile scrivere codice multi-thread, in quanto non hanno il loro strumento più "prezioso" a loro disposizione.

Uso un debugger come ultima risorsa e generalmente solo nel codice non strutturato, quando è difficile trovare una dimostrazione.

Le cose su cui dovresti appoggiarti sono:

• Previene lo stato (il motivo principale per cui è necessario un debugger)
• Prevenire percorsi di codice complessi (un altro motivo)
• Utilizza unit test (trova i bug in precedenza)
• Cerca di trovare una prova del fatto che i tuoi algoritmi funzionano esattamente come fanno
• Documenta le condizioni pre e post dei tuoi metodi (
• Revisione tra pari del tuo codice

Questi dovrebbero darti fiducia nelle cose che stai scrivendo.

Mentre raramente scrivo codice Java oggigiorno, mi affido alla libreria ipdb (o Werkzeug shell di debugger basata su HTML / AJAX) per accedere a un ambiente interattivo in cui posso manipolare gli oggetti in quel determinato stack frame.

Spesso è uno strumento inestimabile per la programmazione esplorativa.

Con Java (principalmente in Eclipse), tendo ad usare gli orologi e il debugger più o meno allo stesso modo, per esplorare lo stato della macchina su un dato punto di programma e cercare di ottenere una certa comprensione da esso. Io davvero mi aiuta a essere più produttivo e a capire meglio il codice degli altri.

Dovresti essere in grado di ragionare attraverso il codice senza l'uso di un debugger. È bello che tu lo stia usando e sì, ha un effetto. A volte è più veloce ed efficiente eseguire il codice e vedere come cambia le cose piuttosto che risolverlo solo leggendo il codice.

Penso che sia una buona pratica e in qualche modo una replica dell'approccio basato sui test. Passando immediatamente al codice, il programmatore lo sta testando da solo.

Tuttavia, penso anche che il programmatore dovrebbe avere fiducia nel codice che ha scritto e non dovrebbe scrivere codice di cui non si fida per vedere come si comporta all'interno dell'ambiente di debug. Questo, di sicuro, porterà all'inefficienza.

Inoltre, non dimenticare che ci possono essere ambienti in cui potresti non avere la possibilità di eseguire il debugger. Ho avuto un problema in cui dovevo lavorare su un codice base che non avevo il lusso e il tempo di impostare il debugger per. Il codice doveva solo funzionare. Per fortuna era una piccola area per la modifica e per fortuna ha funzionato.