Come dedicare meno tempo al debug? [chiuso]

Seguendo la regola di Pareto, un programmatore trascorre solo il 20% del suo tempo in cose davvero utili.

Dedico l'80% del mio tempo al debug, riparando piccole cose per far funzionare tutto.

C'è un modo per dedicare meno tempo al debug?

Codice in Agda o Coq . Una volta compilato il codice, funzionerà. Se è troppo hardcore, scegli una lingua con un sistema di tipo più debole, ad esempio Haskell o F #.

Tuttavia, nella maggior parte dei casi sarai molto più produttivo spendendo il 20% del tuo tempo in programmazione e l'80% in test e debug. Il 100% di una settimana è molto più del 20% di un'ora. Se il debug è ciò di cui hai bisogno per fare le cose, il debug non è una perdita di tempo e non dovresti preoccuparti di "migliorare" questa proporzione.

Test unitari.

Dopo aver iniziato ad applicare i test unitari ho scoperto che il codice che ho scritto è diventato meglio strutturato. È stato quindi più facile evitare e individuare i bug. Ho impiegato meno tempo per il debug, ma più tempo con la scrittura di unit test.

Penso anche che il tempo investito nei test unitari abbia un ritorno dell'investimento migliore rispetto al debug. Dopo una sessione di debug ho appena corretto il codice. Lo stesso bug può comparire settimane dopo e devo eseguire nuovamente il debug. Se scrivo un test unitario, il bug viene documentato come test unitario e successivamente funge da test di regressione. Se il bug appare di nuovo, i test unitari me lo rivelano.

• Test unitari, in modo da sapere se il codice funziona in primo luogo.
• Almeno un po 'di design iniziale, in modo da sapere cosa stai codificando.
• Revisioni del codice, perché due teste sono meglio di una e quattro occhi sono meglio di due. Per non parlare del fatto che anche provare a spiegare il tuo codice a qualcun altro rivela molti problemi.
• Controllo della versione, in modo da poter isolare rapidamente quali modifiche potrebbero aver causato il bug.
• Rifattorizzare, in modo che il codice non si trasformi in un orribile pasticcio incomprensibile.
• Leggi "Clean Code" di Robert C. Martin e fai quello che ti dice. Rimarrai stupito dai risultati.

I test unitari saranno utili se si introducono dei bug che si romperanno prima del codice di produzione - test unitari ben scritti ti diranno anche esattamente cosa si è rotto.

Questo ti porterà per la maggior parte del tempo, ma per il 99,999% dei progetti dovrai ancora eseguire il debug delle cose di volta in volta. La cosa migliore da fare qui che trovo è fare 4 cose:

1. usa i tipi immutabili ove possibile - se qualcosa ha un valore sbagliato saprai esattamente dove cercare immediatamente (dove viene costruito).
2. applicare gli invarianti nel codice: se si sa che un valore non è assolutamente consentito, verificarlo e lanciare un'eccezione nei punti di ingresso a metodi e costruttori. Se lo combini con tipi immutabili, puoi anche iniziare a fare alcune ipotesi su ciò che è valido o meno.
3. assicurati di avere una registrazione adeguata: procedi in anticipo e ti fornirà molte informazioni importanti su quando le cose vanno male. AOP funziona davvero bene qui. La registrazione come ripensamento di solito è un po 'spazzatura: procuratela all'inizio della configurazione del progetto.
4. se la tua base di codice è abbastanza grande / complessa, evita di usare le primitive, ad esempio usa un tipo chiamato "Age" piuttosto che usare semplicemente un int. All'inizio sembrerà un po 'inutile, ma essere in grado di rintracciare tutti gli usi di qualcosa in un istante è un'enorme vittoria di debug.

Il mio 80% è debug. Sto risolvendo semplici bug e sto cercando di far funzionare tutto.

Inizia scrivendo unit test e cerca di avere la massima copertura possibile. Qualcuno ha menzionato TDD, ma andrei con BDD .

Alla fine, molto probabilmente spenderai l'80% per il debug di bug complessi.

Come dedicare meno tempo al debug? Scrivi meno codice.

Seriamente, finché scrivi il codice, dovrai eseguirne il debug. I test unitari ecc. Aiutano immensamente, ma non pensare che rimuoverai mai del tutto.

Comprendi cosa e perché prima di iniziare a scrivere codice. Quindi utilizzare una metodologia in modo coerente. Quale metodologia scelta non è così importante quanto l'uso ripetuto coerente della metodologia. Se vuoi risultati costantemente buoni, devi fare sempre un buon lavoro e avere un "metodo per la tua follia" è il primo passo per ottenere questi risultati. Man mano che identifichi i problemi, puoi adattare la tua metodologia secondo necessità e nel tempo migliorerai il tuo processo di sviluppo e, auspicabilmente, meno bug e uno sviluppo più nuovo e significativo.

Dai una lettura attenta al tuo codice prima ancora di compilarlo. Una lettura molto attenta per sintassi e funzionalità. Può essere sorprendentemente informativo, ed è anche un buon indicatore se una sezione di codice è troppo complicata.

La maggior parte delle risposte sembra focalizzata su come ridurre il numero di problemi che è necessario eseguire il debug e questo è prezioso. Tuttavia, il debug sarà sempre necessario, quindi è utile cercare modi per accelerare il debug.

• Sapere come utilizzare il software di controllo della versione.

  • L'uso delle filiali ti aiuterà a separare le aree di sviluppo e sarai in grado di vedere quale area di sviluppo ha il bug e quali no.
  • Scopri come usare la bisection nel tuo VCS, Git ha questo integrato. Se usi un VCS diverso che non ha bisection incorporato, cerca uno strumento che funzioni come git bisect ma per il tuo VCS (so che esiste per SVN e non dovrebbe essere troppo difficile da creare per altri VCS). Questo ti aiuterà a restringere la modifica del codice che ha introdotto il bug, che ti aiuterà a sapere dove puntare il tuo debugger. Questo processo di bisection sarà più veloce se si hanno test per il bug e sapere quale commit contiene la modifica offensiva sarà più utile se si praticano commit atomici.

• Migliora la tua comprensione del linguaggio di programmazione che usi.

  • Leggi libri, blog e codici sul linguaggio di programmazione.
  • Ogni volta che correggi un bug, assicurati di comprendere a fondo perché il codice non ha funzionato e perché la correzione funziona. Nel tempo imparerai molti gotcha nella tua lingua che ti aiuteranno ad evitare i loro problemi e individuare i loro sintomi nel caso in cui dovessero ripresentarsi.

• Sii logico

  • Non cambiare più di una cosa alla volta, altrimenti se il comportamento cambia non saprai quale cambiamento ha causato il cambiamento nel comportamento.
  • Verifica i tuoi presupposti.

Aggiungendo ai commenti per Unit Testing, ma è davvero buono solo se il codice è stato separato per supportarlo (ad esempio MVC). Se non è possibile implementare MVC (o simile) (progetto legacy), i test unitari non funzionano affatto per l'interfaccia utente. Vorrei quindi aggiungere il test automatico dell'interfaccia utente (Test codificati dell'interfaccia utente Microsoft, WaitN) in quanto ciò ridurrà gli errori in quella parte del codice.

Consiglio vivamente anche l'esecuzione di strumenti di analisi statica (ad esempio FxCop / Microsoft Code Analysis, Resharper, JustCode per il mondo MS). Questi possono trovare tutti i tipi di problemi di codifica comuni che possono ridurre le sciocche attività di debug e concentrarsi maggiormente sul debug della logica aziendale.

Fallo funzionare, quindi fallo velocemente, poi rendilo carino. La maggior parte dei bug proviene da ottimizzazioni anticipate o re-factoring su righe di codice che andavano benissimo. Se segui l'orientamento agli oggetti, non ripeterti, mantieniti semplice e fai sempre controlli di integrità degli intervalli di valori, specialmente se i tuoi metodi continueranno a funzionare con vincoli. Non ti aiuterà a fare meno errori, ma probabilmente ti aiuterà a individuare i bug più velocemente e quindi il debug richiede meno tempo.

Di recente ho riflettuto molto su questo problema: la semplice risposta è leggere The Design of Everyday Things di Don Norman; Scrivi il codice come se dovessi progettare un prodotto.

Per parafrasare, un buon design riduce al minimo l'errore. Ciò significa che alcune cose, la maggior parte delle quali già fai (anche se potresti non sapere esattamente perché ).

-Il nome funziona in modo intuitivo. Questo è formalmente noto come convenienza. Cioè, un pulsante consente di essere premuto, una leva consente di cambiare, una maniglia da tirare, ecc.

-Fai fatica a scrivere codice errato. Controlla l'input errato e genera errori prima o poi, usa le app ungherese quando appropriato, ecc. Queste sono chiamate funzioni di blocco.

-Utilizzare l'astrazione ove appropriato. La memoria a breve termine è debole.

-La documentazione è ovviamente importante, ma è la meno efficace per assicurarsi che il codice sia usato correttamente. In breve, i prodotti ben progettati non richiedono alcuna documentazione. (Il modo più ovvio per vederlo è guardare a cattivi esempi: vale a dire, porte con maniglie che dovresti spingere.)

-Unità test. Questi non impediscono davvero gli errori, tanto quanto rendono ovvio dove si trovano i bug e forniscono buonsenso.

Sono sicuro che mi mancano molti più principi, ma il punto è, leggere sulla progettazione per errori.

Il modo migliore per ridurre il debug, IMO, è concentrarsi e rallentare durante la codifica. Questo ti costringe a vedere gli errori che potresti aver fatto!

Mentre supporto totalmente i test unitari suggeriti sopra, TDD o BDD saranno di grande valore in quanto è necessario innanzitutto pensare al problema e alla soluzione.

Ma personalmente per me, impiegando qualche minuto solo per sedermi tranquillamente e pensare al problema e come affrontarlo e qualsiasi pro e contro con ogni approccio, fa miracoli per la mia qualità del codice e aiuta a liberare la mia mente dal disordine.

A volte uno scarabocchio veloce su un pezzo di carta ti aiuta a vedere i pezzi collegati più grandi del puzzle.

Scrivo il codice peggiore quando mi tuffo per primo nella testa e premo la tastiera. Un po 'di pensiero e contemplazione fa la differenza.

PS. Voglio dire 5 forse dieci minuti, non ore a scrivere una grande specifica.

Alcune buone risposte già, solo un po 'più di cibo per se in aggiunta a ciò che altri hanno detto.

Imparare dai propri errori. Non continuare a fare gli stessi ancora e ancora.

Assicurati di coprire i casi limite durante la programmazione: quelli sono luoghi in cui ci sono spesso bug.

Prestare attenzione al requisito. Anche se funziona ma non fa ciò che il requisito specificato, è un bug.

I registri delle eccezioni possono essere di grande aiuto quando qualcosa va storto tra sei mesi. Avere l'abitudine di registrare le eccezioni.

I miei due pensieri principali sono 1) Scrivi un codice migliore che fallirà quando fai qualcosa di inaspettato 2) Diventa migliore al debugging

Il mio codice è disseminato di

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Ogni volta che eseguo quel pezzo di codice viene generata l'eccezione che provoca l'arresto del debugger che mi consente di programmare le nuove funzionalità o evitare le condizioni piuttosto che confondermi su ciò che sta accadendo / avere un bug

Per migliorare il debugging in giro con lo stack di chiamate, i punti di interruzione (con condizioni), la finestra immediata (nota anche come finestra prompt o sostituisci), le variabili "watch" e quant'altro.