To debug is to problem solve, and problem solving is easier when you have steps to follow. Here are some things I've been thinking more about. I think we all do these things implicitly when debugging, but inspecting how you do something is the first step to improving it.
I'm writing this for myself too, I want to be more conscious about the approach I'm taking when debugging something.
I've found 3 ways to look at a problem while debugging
- What is the problem I am trying to solve?
- Does my code do exactly what I thought it did when I wrote it?
- What tools do I have available and which should I use here?
Ask "What is the problem I am trying to solve?"
Put the problem into words. As the saying goes, if you can't describe it, you don't understand it. This is as true for the problem, as it is for the solution.
Be as clear as possible, write it down if you have to. Try rephrasing the problem. Try explaining it to someone, or something else (rubber ducking).
When you are very sure, and can easily state what you expect, versus what you are getting, you can then move on to the next step.
Does this code do what I think it does?
Once you understand a problem, you must explain it to the computer. Sometimes what you're saying and what the computer is hearing are different. Sound wacky? I'll explain.
Do this while stepping through the code. Before a line executes, tell yourself "I expect this line to do xyz", then step over it and output or inspect the result.
How well do you know the function you're calling? Did you write it? Does it behave differently depending on certain parameters?
Read the documentation, read it again. If you don't have the documentation, you'll need to read the code really carefully. It can feel slow, like you're not making progress, but it's time well spent. Add your own comments as you go, document other's code where there is none.
In desperate cases (when you're calling old libraries written by developers long gone), you may even need to write a number of new tests that inspect a method many different ways so you can be sure it will work for the case you are using it
for.
When the answer is not obvious, you can begin writing small hypotheses. "I if...?", and then go about proving these.
What tools do I have available and what should I use here?
Tools are simply ways to break the problem down further, which is why I've left them for last on this list.
Are you logging output? What about the web server logs, have you checked those?
Sometimes just looking at something like the network requests, or Event Viewer, or a Profiler will cause your brain to think a little more creatively.
Show the results you're getting to someone else, as them if they expect the same result. Why? Why not?
Summary
If you have any concepts around debugging please do share them, and of course questions and comments are welcome.
Top comments (0)