debugging tips
Excellent article at http://www.javaworld.com/community/node/2927
1) Be disciplined. Debugging is a process, said one developer, not a series of random events. Don’t randomly tweak knobs; follow the code’s execution process. Just like fixing a lawnmower, he said. Does part A get the input it needs? How about the output? If that’s OK, move on.
2) To improve your skills, debug other people’s code rather than your own. It will be easier to see the faults in the other person’s assumptions than it is to see your own. You might do this as part of a cross-peer code review and cross-peer debugging. You will develop the ability to recognize the common causes of defects more quickly, promised one developer, and teach you to recognize (and abandon) your own bad development practices.
3) Pretend you’re the compiler. Find and correct as many errors as you can before pressing the Compile button. While most modern IDEs include integrated debuggers (like Visual Studio’s Intellisense), you’ll learn less from their automation than you will from consciously examining the process. (The same way you’ll never learn to spell correctly by relying on a spell checker to do all the work.)
4) Learn to fix bugs as early in the development process as you can. That might mean something formalized, such as test-driven development. That also means devoting time to debugging your design instead of barreling into coding.
5) Debugging is easiest when you can hold the whole system in your head. Don’t make the mistake of focusing in on only one part of an application. Pay attention to the interrelationships between modules. Read the code at multiple levels of abstraction, advised one programmer. “Finding the bug is the hardest part, and it takes clear understanding of what multiple pieces of the code are doing.”
6) Part of the same bit of advice, I think, is someone else’s suggestion: gain a good understanding of the system one level down from what you are working on. “If you are debugging a system level C program, it helps to know some assembly and something about the OS,” explained a system software lead engineer. “If you are debugging a J2EE app, it helps to know something about Java threads, RMI and GC.” In many cases, he pointed out, error messages come from that one-level-down. “If you can understand what that means, it will help you figure out what is going wrong at your level of abstraction,” he explained.
Ebook related to this … “Why Programs Fail”
