Come spendere meno tempo per il debug? [chiuso]

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

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

Test delle unità.

Dopo aver iniziato ad applicare i test delle unità ho scoperto che il codice che ho scritto è diventato più strutturato. Era quindi più facile da evitare e individuare i bug. Ho impiegato meno tempo per il debug, ma più tempo con il test dell'unità di scrittura.

Penso anche che il tempo investito in test unitari abbia un migliore ritorno dell'investimento, quindi il debugging. Dopo una sessione di debug ho corretto il codice. Lo stesso bug può comparire settimane più tardi e devo eseguire di nuovo il debug. Se scrivo un test unitario, il bug è documentato come test unitario e successivamente funge da test di regressione. Se il bug appare di nuovo, i test unitari me lo rivelano.

• Test delle unità, in modo da sapere se il tuo codice funziona in primo luogo.
• Almeno un certo numero di progetti iniziali, in modo che tu sappia cosa stai codificando.
• Recensioni 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.
• Refactoring, in modo che il codice non si trasformi in un pasticcio incomprensibile orribile.
• Leggi "Clean Code" di Robert C. Martin e fai ciò che ti dice. Sarai sorpreso dai risultati.

Il testing delle unità ti aiuterà, come auspicabilmente, a introdurre bug che si interromperanno prima del tuo codice di produzione: test unitari ben scritti ti diranno esattamente cosa è stato rotto.

Questo ti consentirà di ottenere il massimo dal programma, ma per il 99,999% dei progetti dovrai comunque eseguire il debug delle attività da tempo. La cosa migliore da fare qui è trovare 4 cose:

1. usa tipi immutabili ogni volta che è possibile - se qualcosa ha un valore sbagliato, saprai esattamente dove cercare immediatamente (dove è in costruzione).
2. applica gli invarianti nel codice - se sai che un valore non è assolutamente consentito, controllalo e lancia un'eccezione nei punti di ingresso ai metodi e ai costruttori. Se lo combini con tipi immutabili, puoi anche iniziare a formulare alcune ipotesi su ciò che è valido o meno.
3. assicurati di avere una registrazione adeguata: fai in modo che funzioni presto e ti fornirà molte informazioni importanti su quando le cose vanno male. AOP funziona molto bene qui. Eseguire il logging come un ripensamento è di solito un po 'spazzatura: farlo precocemente durante la configurazione del progetto.
4. se il tuo codice base è abbastanza grande / complesso evita di usare le primitive - ad es. avere un tipo chiamato 'Age' piuttosto che usare solo 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.

My 80% is debug. I am fixing simple bugs and trying to make all working.

Inizia scrivendo i test delle unità e cerca di avere la massima copertura possibile. Qualcuno ha menzionato TDD, ma vorrei andare con BDD .

Alla fine, molto probabilmente passerai l'80% sul debug di bug complessi.

Come impiegare meno tempo per il debug? Scrivi meno codice.

Seriamente, finché scrivi codice, dovrai eseguirne il debug. I test unitari ecc aiutano immensamente, ma non pensate di eliminare del tutto la necessità.

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

La maggior parte delle risposte sembra focalizzata su come ridurre il numero di problemi che devi eseguire il debug e che è prezioso. Tuttavia, il debugging sarà sempre necessario, quindi è utile esaminare i modi per velocizzare il debugging.

• Sapere come utilizzare il software di controllo della versione.

  • L'uso dei rami 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 bisezione nel tuo VCS, Git ha questo built-in. Se usi un VCS diverso che non ha bisection costruito in cerca di uno strumento che funzioni come git bisect ma per il tuo VCS (so che questo esiste per SVN e non dovrebbe essere troppo difficile da creare per altri VCS). Questo ti aiuterà a restringere il codice al cambiamento che ha introdotto il bug, che ti aiuterà a sapere dove indirizzare il tuo debugger. Questo processo di bisezione sarà più veloce se hai dei test per il bug e sapendo quale commit contiene il cambiamento offensivo sarà più utile se pratichi i 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 capire bene perché il codice non ha funzionato e perché la tua correzione funziona. Con il passare del tempo imparerai molti trucchi nella tua lingua che ti aiuteranno a evitare i loro problemi e ad individuare i loro sintomi nel caso si verifichino nuovamente.

• Sii logico

  • Non cambiare più di una cosa alla volta altrimenti se il comportamento cambia non saprai quale cambiamento ha causato il cambiamento di comportamento.
  • Verifica le tue ipotesi.

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

Raccomando anche di eseguire gli 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 di business.

Falla funzionare, quindi rendila veloce, quindi rendila carina. La maggior parte dei bug proviene dalle prime ottimizzazioni o dal ri-factoring su righe di codice che erano assolutamente soddisfacenti. Se vai con l'orientamento all'oggetto non ripeti te stesso, mantienilo semplice e fai sempre dei controlli di integrità degli intervalli di valori, specialmente se i tuoi metodi continueranno a funzionare a 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.

Mi è stato dato molto tempo per riflettere su questo problema - la semplice risposta è andare a leggere The Design of Everyday Things di Don Norman; Scrivi un codice come se progettassi un prodotto.

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

-Name funziona intuitivamente. Questo è formalmente noto come affordance. Cioè, un pulsante consente di essere premuto, una leva consente di essere commutata, una maniglia da tirare, ecc.

-Fai difficile scrivere codice errato. Verifica la presenza di input errati e genera errori prima o poi, usa app ungherese quando appropriato, ecc. Queste sono chiamate funzioni di blocco.

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

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

- Esegui test. Questi in realtà non impediscono gli errori, al punto da rendere ovvio dove sono gli errori e forniscono sanità mentale.

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

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

Pur supportando totalmente i test delle unità suggeriti sopra, TDD o BDD saranno di grande valore in quanto è necessario innanzitutto pensare al problema e alla soluzione.

Ma personalmente per me, prendermi 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 svuotare la mia mente dal disordine.

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

Scrivo il codice peggiore quando mi tuffo per primo in testa e suona la tastiera. Un po 'di pensiero e di contemplazione fanno un mondo di differenza.

PS. Intendo 5 forse dieci minuti, non ore scrivendo una grande spec.

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

Impara dai tuoi errori. Non continuare a creare gli stessi più e più volte.

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

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

I registri delle eccezioni possono essere di aiuto quando qualcosa va storto tra sei mesi. Prendi 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) Migliora nel debugging

Il mio codice è pieno 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 lanciata un'eccezione che causa l'arresto del debugger che mi consente di codificare le nuove funzionalità o di evitare le condizioni piuttosto che confondermi su cosa sta succedendo / avere un bug

Migliorare il debugging con lo stack delle chiamate, i breakpoint (con condizioni), la finestra immediata (nota anche come prompt o repl), le variabili "watch" e quant'altro.