Debugging. Ways to do it and what to take care of while doing it
A bug in an application represents the incorrect functioning of an entity, when the expected result is not returned. A bug is not always an code error. While an error is most of the time very easy to spot and fix, a bug can have no indication from where the problem appear. The action of finding and fixing a bug is named as debugging.
Debugging can be difficult and time consuming. Sometimes is a small thing which you can spot fast and fix, but sometimes is a nightmare. I am currently working on complex project were I have to debug a lot and I thought is a good moment to write about how to do it to make your live easier.
First, don't be afraid of debugging in the hardest way.
The risk of not debugging at the right time
Most developers will avoid the hardest debugging journey just to finish faster the work without considering later problems that can appear. A bug not found at the right time can make a developer and a company want to abort the entirely work when the deadline is getting closer.
Avoid ineficient time spend on debugging
Debugging requires a lot of involvement.
Brainstorming, creating stories and discussing them with people that know what the project has to do, removing unnecessary code and a lot of focusing with taking brakes.
Taking brakes is very important because you can easily get tired and become inefficient very fast. When you feel you are loosing track of the things you fallow, just take a break. Go outside for 30 minutes, or get involved in a different thematic discussion with a mate...give a call. Anything will make you get distracted from your work will help you focus better when you will return. Always, after a brake you will see things with different eye and you might spot the problem in 5 minutes when before you couldn't in 4 hours.
The fastest solution to a problem is not always the best one. Sometimes you need to take things from scratch.
A good way to find a complicated problem in a large code is to isolate the code by removing anything is not needed, commenting code unrelated to the part of the project that is tested or moving it to a project copy. It is a hard process, but is a good way to reduce as much as possible the section of the code where you need to search for the bug. Is also a good way to get the part of the code that is failing, out of the project and make it run as a standalone project...if possible.
Reorganise the code. Many times an error can rise only because your code missed an else (and this one can be so annoying because is not even bringing an error. The code just stops it's execution where the else is missing). Imagine that somebody else wrote this code and you jump on it to do more work or to do fixes. You basically need to start by reading it all. At least the section where you know you are working, but is a good thing to understand the image of the entire project.
Rewrite the code if you see something is not properly written. Don't just leave it because is working or you believe is working. This is not enough.
Add comments on the code you read and understand, to can go over it more easy next time when you need to do so.
Correct the formatting on the code if is messy written. A code can be more easy understood if it has the wright alignment and indentation.
Always use Git and backup you work. When debugging on something hard try to make a plan. Many times you will end by having multiple plans. If your first plan didn't work, don't just revert the code to what you had initially if it didn't helped. The best way is to commit your work to Git on a different branch to be sure that if you start again from scratch it will still be possible to easy return to something you done on the fist attempt to fix.
The most important part: Try not to break what is already working. Even if you rewrite a code, change namings or reorganise the code, what it was working already must work the same. Your changes should bring a plus of functionality not make things worst. :)
All this process will apply only when is not pressure on you. Pressure will make you go with the simplest way to solve the problem and this will only be a temporarily fix that will bring more problems further along the road.
I just finished my break from the work I do. Now, let's get back on debugging.