The Elements of Surprise
When something goes wrong, the amount of surprise we feel is directly proportional to the amount of faith we have in our code. This is the main reason that makes us think that there is something wrong with the library or the third party code we use. We must realize that one of our assumptions might have gone wrong. Prove it, if it is not, by checking all the boundary conditions.
Don't Assume It—Prove It
When we come across a surprising bug, take some time to think why it wasn't caught earlier. Merely fixing the code may cause the bug to happen again. Always check whether there are any other areas of code susceptible to the same bug. If yes, find and fix them. If bug fixing takes a longer time, ask ourselves the question: why? If the bug occurred due to somebody’s wrong assumption, discuss the same with the whole team. If one person assumes incorrectly, there is a greater chance that others may also go wrong.
Do all this, and hopefully you won't be surprised next time.
Debugging Checklist
- Is the problem being reported a direct result of the underlying bug, or merely a symptom?
- Is the bug really in the compiler? Is it in the OS? Or is it in your code?
- If you explained this problem in detail to a coworker, what would you say?
- If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
- Do the conditions that caused this bug exist anywhere else in the system?
- summary of Debugging, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment