Risposte:
Non dare per scontato nulla
Spesso è allettante dire semplicemente "oh, so cosa sta facendo questo codice, va bene". Non farlo. Metti alla prova ogni ipotesi e passa in rassegna tutto con attenzione.
Test in modo incrementale .
Approfondisci prima il codice e testalo dal modulo più piccolo che si sposta gradualmente verso l'alto, in questo modo non sei troppo stressato cercando di capire dove potrebbe essere esattamente il problema.
Significa anche che influenza meno codice alla volta poiché ti stai spostando in modo incrementale ... come a volte ho avuto problemi in cui ho risolto qualcosa e che porta a rompere molte altre cose. Rendo merito al mio capo per questo mentre mi ha insegnato questo quando ho fatto un casino.
Dividere e conquistare è un buon approccio. Prova a identificare alcuni input visibili (input utente / evento di rete ...) e output (registro, output per l'utente, messaggio di rete in uscita ...) tra cui esiste il problema. Prova a mettere stampe in blocchi considerevoli o punti significativi tra loro e cerca di restringere la posizione del bug nel codice.
Divide and conquer può anche funzionare molto bene in caso di regressioni rispetto al codice controllato dalla versione. Trova due build: una dove funziona come previsto, l'altra con la regressione. Riduci il divario fino a quando non rimani con un mucchio di check-in come potenziali sospetti.
Invece di tagliare il bug binario, scrivi i test nel modulo
Per verificare ciò che effettivamente sai essere vero sul funzionamento dell'app rispetto a ciò che ritieni essere vero.
La maggior parte degli IDE semplifica l'estrazione di metodi e la generazione di stub di test xUnit. Usalo.
Perché non cospargere i debug? Perché dopo aver finito, probabilmente dovrai annullare gran parte di tale lavoro ed eliminare una buona quantità di tali debug. Quando scrivi i test, il tuo debug ti aiuterà nella prevenzione e nel rilevamento di futuri bug.
Come altri hanno già detto, non dare per scontato nulla. Ciò è particolarmente vero se hai scritto il suo codice. Quando esegui il debug di altri codici, è più probabile che rallenti perché il codice è nuovo per te o non ti fidi del programmatore. Quando esegui il debug del tuo codice è troppo facile presumere che tu l'abbia scritto correttamente, rallenta!
Per l'effettivo processo di debug:
Aggiunta dei test unitari e registrazione prima più efficiente dell'utilizzo del debugger. Hai anche il vantaggio di avere i test unitari per non introdurre bug futuri e la registrazione aiuterà le sessioni di debug in futuro.
Prima di scavalcare un piccolo pezzo di codice, vedi se riesci a determinare con precisione il risultato. Questo tende a volare di fronte a non dare per scontato nulla (che ho votato a proposito BTW) ma man mano che acquisisci esperienza, può aiutare a restringere il punto in cui cercare.
Questo può sembrare banale, ma impara le sfumature del tuo debugger e impara i tasti di scelta rapida. A volte i debugger possono essere abbastanza lenti che la tua mente si chiede quando passi. Se riesci a tenere il passo con la macchina e non stai scherzando, questo può aiutare.
Se è possibile modificare il codice durante il debug:
piace:
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
invece di:
if ( a < 5 || a > 10 )
{
// more code here
}
Per i casi non è possibile eseguire il debug di tutto, per qualsiasi motivo, imparare a "paperella di gomma" con un collega. A volte l'atto di spiegare fa luce. (ok, forse questo non è esattamente nel tema delle domande, ma penso che sia abbastanza vicino da giustificare la menzione)
Due cose, basate sul passare la maggior parte degli ultimi 22 anni a mantenere il codice scritto da altre persone.
Comprendi i tipi di bug che tendi a scrivere.
Ad esempio, sono un programmatore molto meticoloso, quindi una volta compilato il mio codice, di solito è privo di bug banali. Quindi i miei bug tendono ad essere strane cose complicate come i deadlock dei thread. Il rovescio della medaglia, ho un amico che scrive principalmente bug banali - punti e virgola alla fine di C ++ per i loop, quindi la riga successiva viene eseguita solo una volta, quel genere di cose.
Non dare per scontato che altre persone scrivano gli stessi tipi di bug che fai.
Non so quante volte ho perso tempo a estrarre le grandi pistole di debug, supponendo che un bug fosse il mio tipo di cosa strana davvero sottile, solo per avere il mio amico guardarmi alle spalle e dire "Hai notato quel qualcosa in più punto e virgola?" Dopo anni di questo, per prima cosa vado a cercare il frutto banale e basso quando guardo il codice di altre persone.
Conosci i tuoi strumenti. Ad esempio, il debugger di Visual Studio ha una fantastica funzionalità chiamata TracePoints che sono come punti di interruzione ma invece di interrompere il codice inserisce invece un'istruzione trace nell'output di debug.
Si consiglia vivamente di leggere libri o seguire un corso su come utilizzare il debugger. Ho preso un paio di lezioni e ho letto alcuni libri di John Robbins che hanno fatto una grande differenza nella mia efficacia come debugger.
Scrivi unit test automatici e altri tipi di integrazione e test funzionali.
Più test automatici hai, meno tempo devi dedicare a un debugger.
Inoltre, un buon design: principi SOLIDI. Se stai scrivendo classi piccole e mirate e preferisci la composizione rispetto all'eredità, eliminando la duplicazione, ecc., Il tuo codice sarà sempre più facile da eseguire il debug.
Trovo che un codice ben progettato produca una serie diversa di bug che codifica che non è ben progettato. In generale, un codice ben progettato produce bug che sono più facili da trovare, riprodurre e correggere.
L'eccezione (e ce n'è sempre una) è il codice multithreading :-)
Se l'hai ridotto a una piccola area, ma non riesci ancora a individuare l'errore, prova l'opzione "Visualizza codice + assembly" del tuo debugger. Conoscendo abbastanza ASM per dire "qui dovrebbe esserci un ramo" o "perché sta solo copiando la parola bassa?" spesso individuerà l'errore di codifica.
Dai un'occhiata al prezioso libro Perché i programmi falliscono: una guida al debug sistematico , di Andreas Zeller. Ti introdurrà a molte tecniche, teorie e strumenti, alcuni dei quali all'avanguardia della ricerca.
Le diapositive per il libro sono disponibili online, ma trovo che il libro stesso sia più facile da leggere.
Il libro ti aiuterà a iniziare e ti farà pensare in modo più scientifico al debug, ma non è un sostituto per la pratica. Potrebbe essere necessario scrivere e eseguire il debug per 10 anni prima di vedere un miglioramento delle prestazioni in ordine di grandezza. Ricordo ancora di aver lasciato a bocca aperta Sun vedendo gli sviluppatori senior, che hanno programmato per Unix per 30 anni, a trovare oscuri bug di multithreading o paralleli in pochi minuti. L'esperienza conta!