Update: Development of GapDebug has been discontinued. Read the End of Life Notice for more information.
By Wayne Parrott - Vice President Product Development
"If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra
I can’t recall any team or dev processes I have worked with that provided direction and guidance for debugging practices and tools. This is such an oversight considering 50% of development time is spent debugging. Amazing, huh?
The following slide and talking points are from a talk I gave at PhoneGap Day 2014 on debugging and GapDebug. It outlines a simple debugging workflow and provides a set of guidelines for which every developer should be aware.
Print this chart and post it in your work area. Review it when debugging to help guide your process.
The 3 phases of debugging are presented at the top of the slide. Be explicit by asking yourself, "What phase am I in?" Most of the time it's kind of obvious but...
Detection - In this phase you identify that your system or code is not performing to expectation. Bugs pop up at all phases of development, e.g., design bugs, bugs missed in testing, missing tests or bugs in your test suite, documentation errors... The worst bugs are those that get shipped and are found by your customers.
Isolation - Once you have identified a bug or fault in your system, the next step is to isolate it to its root cause. Is this a design problem? Is it an implementation issue? Some bugs are easy to isolate, others can drive you nuts. Typically you need to replicate the problem and observe it first hand in order to accurately isolate it. Problem replication alone can be troublesome, especially intermittent and concurrency issues.
Resolution & Recovery - This is the fix phase where you implement a solution that resolves the bug. It also includes verifying the fix. If a fix is not verified, then it's not fixed.
9 Rules of Debugging
The 9 rules of debugging are from Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David Agans. I’m not big on rules. So I think of them more as the 9 tips and guidelines for effective debugging. Of these guidelines #3, “Quit thinking and look,” implies fire up your debugger if you’ve got one. Dig into the system and see what’s goofed.
It’s 2015. Use a Debugger.
Today’s modern debuggers are awesome and practically indispensable for rapid development of quality code. Yet I frequently see developers, even experienced developers, neglecting the debugger that is only a click away in their dev environment. Instead they opt to fill up their code with print and alert statements to trace and dump execution state. What’s the deal? When I’ve seen this, words like novice, amateur, and hack come to mind. Expand your skills, learn your tools and get back to coding more quickly. And stop junking up your code with crappy personal debug info that so frequently is left in the codebase commented out!
Debugger Breakpoints Rock!
Start by learning to use your debugger’s breakpoint facility. A breakpoint is a marker you place in the code that instructs the program to suspend execution when encountered. You can then resume program execution from that point. While stopped at a breakpoint you can typically use the the debugger tools to inspect the program’s execution state, such as local and global variables, execution stack and console output.
Environments that support conditional breakpoints, and more recently breakpoint actions (see below), let you replace those code cluttering print statements with clean, conditional breakpoints. With a conditional breakpoint you provide a snippet of code that is evaluated each time the breakpoint is encountered. When the snippet evaluates to true, program execution is suspended at that point. This approach avoids jacking up your code with ad hoc print statements.
And if you’re a Java programmer using an IDE such as MyEclipse, you’re really in for a treat. While program execution is suspended at a breakpoint you can modify the code in the debugger, roll back to an earlier point in the program’s execution and resume. Repeat this as often as required. How cool is that? And you can export and share your breakpoints or reload them for future debugging.
Improving your debugging and trouble-shooting skills helps reduce frustration and gets you back to the creative task of coding. To learn more about becoming a better debugger check out the following resources:
- www.rulesofdebugging.com hosted by David Agans
- Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David Agans
- GapDebug - a free debugger for PhoneGap iOS and Android mobile apps - GapDebug User Guide
|About the Author|
|Wayne Parrott is Vice President of Product Development and co-founder of Genuitec LLC. He brings more than 21 years of software development and application life-cycle management to overseeing development of Genuitec’s successful MyEclipse product family. His debugger work began with MyEclipse's first JSP debugger in 2003. His most recent work is with GapDebug, the first full featured cross-platform debugger for iOS and Android Cordova (PhoneGap) apps.|