8 Brilliant Debugging Ways to Quickly Identify the Problem
Also learn the tips to write code that makes future debugging easier!
If you have done any programming, you will have debugged the code. Without learning to debug, you cannot be a programmer.
But have you spent hours looking at a piece of code just to figure out what the problem is?
Have you pulled your hair to find where the offending line of code is?
Have you ever cursed the day you decided to learn programming as you cannot find the reason for a particular bug?
We have all been there.
But it doesn’t need to happen all the time when you are coding.
There are strategies you can use to find the issue quicker.
Reproduce the issue
This is the first step in any debugging process when you have found a bug in existing code.
Unless you can reproduce the issue on your laptop, it becomes very challenging to fix the issue.
So find ways to reproduce the issue in your development environment a.k.a your laptop.
This is important as then you can leverage the powers of your IDE to do quick debugging.
Now, there are scenarios when this is not possible.
One example, is your laptop does not have all the integrations that are required to reproduce the problem. This can happen when you are working in a distributed architecture.
You can use remote debugging to overcome this issue.
Isolate the problem
For all debugging, whether it is code that you wrote that is not working or an existing bug, you have to isolate the problem.
You should be able to get a general idea of where a bug could be.
One approach is to understand until you think the code seems to be working.
This can be done in a variety of ways.
In most programming languages, simply logging into the console will give you an idea as to when the code is working fine.
But this process is tedious.
So you need to find markers that will tell you when the code is not dodgy.
This could be reading the code you are debugging as it will also help you understand the flow.
The other option is to take help from the existing log statements.
You could also add breakpoints which I mention as the next step. But that will mean longer debugging.
The idea is to get into the vicinity of the code where the bug might be.
Use breakpoints
Once you are in the vicinity of the code, use breakpoints.
As you have isolated the problem in the last step, you can add a breakpoint just before the point where you think the problem code is present.
This is powerful as now you are not going through the code one line after the other.
Step through the code and inspect the variables
Once you reach your breakpoint, start stepping through the code. Also, add a watch on variables that will change state during the process.
This will help you understand the behavior of your code.
Experiment by changing code on the fly
You might already have a suspicion of where the issue could be.
Advanced IDEs can help you change your code on the fly to test the outcomes of those changes.
This will give you a better understanding of whether the code you think is dodgy is actually dodgy.
Read Documentation
Sometimes, you might know what a method is doing in your code.
But it just helps to read the documentation one more time.
It helps you re-visit your understanding and a miss in your understanding could be the problem.
Rubber-ducking
What you do here is imagine a duck and start explaining the code you are troubleshooting to it.
Logical flaws show up when you verbalize your understanding and listen to your own voice.
You can use this technique even to isolate the problem.
Call a friend
Yes, if nothing seems to work - call a friend. This is the next level of rubber-ducking. In rubber-ducking, you are talking to an inanimate object.
When you are talking to a friend, you can get feedback and also get ideas on what other options you can try.
Tips to avoid getting into debugging hell-hole
Write clean code.
Yes, write code the way you want it when you are debugging.
Other tips are:
Use method names that will help you understand what the method is doing.
Put in log statements so that you know what’s happening in the code.
Use meaningful variable names.
Follow SOLID principles
Follow the DRY principle.
Add unit tests.
