Un compito comune nel mondo del lavoro riguarda il codice esistente, ma buggato. Quali sono alcuni suggerimenti per migliorare le tue abilità come debugger?
Non assumere nulla
Spesso si è tentati di dire "oh, so cosa sta facendo questo bit di codice, va bene". Non farlo. Metti alla prova ogni ipotesi e passa attraverso tutto attentamente.
Test incrementale .
Vai in profondità prima nel tuo codice e provalo dal modulo più piccolo che si sposta gradualmente. In questo modo, non sei troppo stressato per cercare di capire dove potrebbe essere esattamente il problema.
Significa anche che influisce meno codice alla volta da quando si sta spostando in modo incrementale ... a volte ho avuto problemi in cui ho risolto qualcosa e questo ha portato alla rottura di molte altre cose. Rendo merito al mio capo per questo, come mi ha insegnato questo quando mi sono incasinato.
Dividere e conquistare è un buon approccio. Prova a identificare alcuni input visibili (input dell'utente / evento di rete ...) e output (log, output per l'utente, messaggio di rete in uscita ...) tra cui esiste il problema. Prova a inserire stampe in blocchi considerevoli o punti significativi tra loro e cerca di restringere il punto in cui il bug si trova nel codice.
Dividere e conquistare può anche funzionare molto bene in caso di regressioni rispetto al codice di versione controllata. Trova due build: una in cui funziona come previsto, l'altra con la regressione. Restringi il vuoto fino a che non ti rimane un gruppo di check-in come potenziali sospetti.
Piuttosto che il chop binario, scrivi test nel modulo
Per verificare ciò che effettivamente sai essere vero sul funzionamento dell'app rispetto a quello che ritieni sia vero.
La maggior parte degli IDE facilita l'estrazione di metodi e la generazione di stub di test xUnit. Sfrutta questo.
Perché non cospargere i debug? Perché dopo aver terminato, probabilmente dovrai annullare gran parte di quel lavoro ed eliminare una buona parte di questi debug. Quando scrivi dei test, il tuo debug aiuterà nella prevenzione e nel rilevamento di futuri bug.
Come altri hanno già detto - non dare per scontato nulla. Questo è particolarmente vero se il codice che hai scritto. Quando esegui il debug di un altro codice, è più probabile che tu rallenti perché il codice è nuovo per te o non ti fidi del coder. Quando esegui il debug del tuo codice è troppo facile presumere di averlo scritto correttamente, rallenta!
Per il processo effettivo di debug:
Aggiungendo i test unitari e la registrazione prima più efficienti usando prima il debugger. Hai anche il vantaggio di avere i test unitari per aiutarti a non introdurre futuri bug e il logging ti aiuterà a eseguire il debug delle sessioni in futuro.
Prima di calpestare una piccola porzione di codice, verifica se è possibile determinare con precisione il risultato. Questo tende a volare di fronte a non dare per scontato nulla (che ho votato in BTW) ma man mano che acquisisci esperienza, può aiutarti a restringere dove cercare.
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 facendo il topo, questo può aiutarti.
Se puoi modificare il codice durante il debug:
come:
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 "fare la 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 meritare menzione)
Due cose, basate sulla spesa degli ultimi 22 anni per il mantenimento del codice scritto da altre persone.
Comprendi i tipi di bug che tendi a scrivere.
Ad esempio, sono un programmatore molto meticoloso, quindi una volta che il mio codice viene compilato, di solito è privo di bug insignificanti. Quindi i miei bug tendono ad essere strane cose complicate come thread deadlock. Il rovescio della medaglia, ho un amico che scrive per lo più insetti banali - il punto e virgola alla fine di C ++ per cicli, in modo che la riga successiva ottiene solo eseguito una volta, questo genere di cose
.Non dare per scontato che altre persone scrivano lo stesso tipo di bug che fai.
Non so quante volte ho sprecato il tempo tirando fuori i grossi calibri di debug, assumendo un bug è stato il mio genere di cosa strana davvero sottile, solo per avere il mio amico guardare oltre la mia spalla e andare, "L'hai fatto si noti quel punto e virgola in più? " Dopo anni di ciò, prima mi occupo del frutto banale e pungente quando guardo il codice di altre persone.
Conosci i tuoi strumenti. Ad esempio, il debugger di Visual Studio ha una caratteristica fantastica chiamata TracePoints che sono come punti di interruzione, ma che di fermare il tuo codice inserisce invece un'istruzione trace nell'output di debug.
Si consiglia di leggere libri o seguire un corso su come utilizzare il debugger. Ho preso un paio di lezioni e letto alcuni libri di John Robbins che hanno fatto una grande differenza nella mia efficacia come debugger.
Comprendi funzionalmente ciò che il codice sta tentando di fare. Se non conosci l'immagine completa (tutte le prove che questo codice deve superare) è difficile eseguire il debug correttamente senza introdurre nuovi bug
Scrivi test unitari automatizzati e altri tipi di test di integrazione e funzionali.
Più test automatici hai, meno tempo hai bisogno di spendere in un debugger.
Inoltre, buon design - principi SOLID. Se stai scrivendo classi piccole e mirate e preferisci la composizione sull'ereditarietà, eliminando la duplicazione, ecc., Il tuo codice sarà sempre più facile da eseguire il debug.
Trovo che il codice ben progettato produca un diverso set di bug che il codice non è progettato bene. In generale, un codice ben progettato produce bug che sono più facili da trovare, riprodurre e correggere.
L'eccezione (e ce ne è sempre una) è il codice multithreading :-)
Se lo hai ristretto a una regione piccola, ma non riesci ancora a individuare l'errore, prova l'opzione 'visualizza codice + assembly' del tuo debugger. Conoscendo abbastanza ASM per dire "dovrebbe esserci un ramo qui" o "perché si copia solo la parola bassa?" spesso individuerà l'errore di codifica.
Guarda il 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 sono 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 ea farti pensare in modo più scientifico al debug, ma non è un sostituto per la pratica. Potrebbe essere necessario scrivere e eseguire il debugging per 10 anni prima di vedere un miglioramento dell'ordine di magnitudo nel rendimento. Ricordo ancora di aver avuto la mia mascella a Sun vedendo sviluppatori senior, che hanno programmato per Unix per 30 anni, trovare oscuri multithreading o bug paralleli in pochi minuti. L'esperienza conta!
Leggi altre domande sui tag debugging