Debugging Checklist..
It is a painful thing, To look at your own trouble and know That you yourself and no one else has made it… Sophocles Ajax
No one writes perfect software, so it’s a given that debugging will take up a major portion of your day. Let’s look at some of the issues involved in debugging and some general strategies for finding elusive bugs. 🐛
Psychology of Debugging
Debugging itself is a sensitive, emotional subject for many developers. Instead of attacking it as a puzzle to be solved, you may encounter denial, finger pointing, lame excuses, or just plain apathy.
Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s. It is still your problem.
A Debugging Mindset
The easiest person to deceive is one’s self — Edward Bulwer-Lytton
Before you start debugging, it’s important to adopt the right mindset. You need to turn off many of the defenses you use each day to protect your ego, tune out any project pressures you may be under, and get yourself comfortable.
Above all, remember the first rule of debugging :) Don’t Panic 😫
It’s easy to get into a panic, especially if you are facing a deadline, or have a nervous boss or client breathing down your neck while you are trying to find the cause of the bug.
Where to Start
- Before Solving problem try to reproduce it… ! This one is major trick to look at the problem. In day to day life working as a programmer I use this trick almost every time.
2. You first need to be accurate in your observations.
3. You need to gather all the relevant data.
Rubber Ducking
A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. ..
The other person should look over your shoulder at the screen, and nod his or her head constantly like a rubber duck.. 🦆
They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.
It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through
the code yourself. By having to verbalize some of these assumptions, you may suddenly gain new insight into the problem.
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
- Don’t Assume Prove It..
- Don’t blame third party libraries, databases used in your app.
In My upcoming article i would like to explain debugging with Android App so stay tuned.. 💚
