Before getting into the point of this post, by debug I mean going through each line of source code one after one or step by step. Reviewing the state of the memory at each step (and if you are really interested on how a debugger works under the hood, you can play with a tool I wrote and presented in the post a bit about programming language implementation).
Now, going to the point of this post, I have found, during my experience (which is far from large one) working with other developers, that few of them use the debugger as the first tool for troubleshooting and learning or understand legacy code. My experience is mostly based on Java/Eclipse. If you are familiar with Java/Eclipse, you will know that debugging an application is pretty simple. Indeed, Java allows you to debug remote JVMs. Yes, you are able to debug a JVM deployed in one continent from an Eclipse running on a workstation on another continent. Very nice.
Mostly during my assignments in my undergraduate courses, I used Pascal, C and C++. And a debugger in those languages becomes pretty necessary. Especially if you are trying to find out an issue that may be caused by a dangling reference. So, I have learned those programming languages and learned how to troubleshoot applications using a debugger. On my working experience, I jumped into Java/Eclipse. Java and their Exception mechanisms generates very informative errors making the use of the debugger less necessary than in C (in addition, and among other things, pointers in Java are not managed by the developer which is far less error prone). However, the debugger is still the best tool for troubleshooting and for understanding legacy code.
I have received questions from other developers like: “…when I click on the button X, I get an error page with the suggestion to call the customer service”. My answer is always the same… “Please, use the debugger, and let me know what you find”. In most of the cases, they come after 10 minutes saying something like: “… forget it, it was something wrong I did…”.
Other developers try to understand what is going on looking at the code and trying to follow the flow of the program in their head. Which of course is not easy, and very error prone. Don’t waste your time, please, use the debugger.
If you find an issue, follow these steps:
1. Start the debugger and discover what is going on.
2. Write a unit test that reproduces the issue. You will get the red bar.
3. Fix the issue.
4. Run the unit test you wrote in the step 2, and see if you get the green bar.
5. If you get the green bar, move on.
If you need to deal with legacy code, the debugger is your tool to understand and get the knowledge that later will let you apply light/safe refactors to make the code testable.
Today, you should not choose a programming language to develop an application (even small ones! Unless you just need the Hello World!) which does not provide an IDE for debugging. In addition, your IDE should allow you to run/execute unit tests (and debug them if necessary).