5 Simple Rules To Effective Debugging
1. Use your IDE to debug
As odd as this will sound, many, many programmers I know still does System.out.println() (which easily incurs insults from yours truly) for debugging; slightly smarter ones will use logs. Both will never be as fast or as convenient as using a real debugger in your IDE. I was lucky enough to pick up this valuable skill from my first senior and for that I'll be forever grateful. IDE debugging often allows the following cool features
- hot swapping of code
- object inspection (it doesn't freaking matter if it's a plain object or some fancy data structure)
- execution stack monitoring
- break when variable equals [some value]
- real-time modification of variable value
2. Remember thy shortcut keys
This is applicable to programming in general - mastery of your IDE's shortcut keys isn't a luxury, it's a necessity. What this means is that you need to always be able to step-in, step-out, step-over and continue debugging without even touching your mouse or looking at your keyboard. Memorize each key-stroke for those operations folks (that's F5, F7, F6 and F8 for Eclipse users). This is probably the simplest rule, but it's important nevertheless.
3. Write Unit Tests
How is this related to debugging? Simple. Unit tests by nature are fast to execute and are executable within the IDE. Yes, even if you're using Maven or some other build tools, it is very important to allow tests to be run from within the IDE to facilitate quick debugging. Unit tests are also very atomic, allowing a very narrow execution path, which in turn enables you to zoom in to a small portion of code to debug. Often I've seen folks without unit tests having to fire-up an application server to debug. You lose plenty of time waiting for it to start, only to have to go through the entire waiting game if you should need to change code (naturally this happens often in the debugging cycle). And you know what they say about tests that takes a long time to run... (they don't get executed)
4. Set Correct Breakpoints
If you find yourself having to hit the keyboard to many times to advance the stack, something is wrong. Don't be afraid to start with many breakpoints but start to clear the older ones once you have identify a general flow. I general I try not to have more than 5, 7 at most. If you're using too many breakpoints, your test execution path might be too wide. Consider rewriting a narrower test. You may also wish to consider using conditional breakpoints.
5. You Can Debug Remotely
Yes, it isn't ideal, but if you've got the server up, and the application is acting weird, why not seize the chance to quickly examine the state of the application? Of course this assumes that during development, you have the smarts to start the application using remote debugging VM options:
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
You'll lose the ability to hot swap code, and there's the need to redeploy once you changed code, but these are small inconveniences compared to the ability to view the internals of your application when a bug surfaces (you still retain the other benefits of debugging). Once the examination is done, actual bug fixing and debugging should be carried out via unit tests anyway.