Debugging code - the hard way
I have spent the whole day debugging, it makes value unit tests (junit) even more than usual.
Debugging is such a difficult job when you can only test the code through the front end and checking the extra logging you have put in. The main problem I have with the code I was debugging was that it was using a struts action and almost all of the code was in the main method in the action. This basically meant it was practically impossible to test the code without using the front end and clicking and then reading the log files.
I have done a bit of refactoring but because it took me soooooo long to actually find where the problem was and then why it was going wrong, I am only doing a bit and to be honest it works and it's an action, which is pretty much self contained so it's not that much benefit refactoring it.
Today was a classic case of "everytime you fix a bug you are in danger of adding another bug" which I blogged about earlier blog entry The bug I am fixing today wasn't in the release a couple of releases ago. We found this out by my idea of setting up a running copy of the last few releases so we can easy test the code the different customers are seeing. Anyway the code works fine there so this at least gave me some clue where to start the search on what might be causing the bug. The code was actually a result of someone fixing another bug.
The bug was also quite sneaky because it was a base class that was changed the bug has filtered up which meant it was very tricky to find.
I find bug fixing can be quite boring and frustrating, especially when you are doing it like I was today by using logging messages. I must have wasted loads of time adding comments, recompiling the servlet and stopping/starting Tomcat and then running the program.
The plus side of debugging is that you do get to know the code in detail and sometimes it's quite nice not having to write to much code. Although I do get the feeling of restlessness and like I haven't really done much that day.
The best reason I heard why you should write unit tests is
"you know how long it will take to write a unit test, how long does debugging take"
Debugging is such a difficult job when you can only test the code through the front end and checking the extra logging you have put in. The main problem I have with the code I was debugging was that it was using a struts action and almost all of the code was in the main method in the action. This basically meant it was practically impossible to test the code without using the front end and clicking and then reading the log files.
I have done a bit of refactoring but because it took me soooooo long to actually find where the problem was and then why it was going wrong, I am only doing a bit and to be honest it works and it's an action, which is pretty much self contained so it's not that much benefit refactoring it.
Today was a classic case of "everytime you fix a bug you are in danger of adding another bug" which I blogged about earlier blog entry The bug I am fixing today wasn't in the release a couple of releases ago. We found this out by my idea of setting up a running copy of the last few releases so we can easy test the code the different customers are seeing. Anyway the code works fine there so this at least gave me some clue where to start the search on what might be causing the bug. The code was actually a result of someone fixing another bug.
The bug was also quite sneaky because it was a base class that was changed the bug has filtered up which meant it was very tricky to find.
I find bug fixing can be quite boring and frustrating, especially when you are doing it like I was today by using logging messages. I must have wasted loads of time adding comments, recompiling the servlet and stopping/starting Tomcat and then running the program.
The plus side of debugging is that you do get to know the code in detail and sometimes it's quite nice not having to write to much code. Although I do get the feeling of restlessness and like I haven't really done much that day.
The best reason I heard why you should write unit tests is
"you know how long it will take to write a unit test, how long does debugging take"
posted by The Hosk at
12:36 am
2 Comments:
Well, the kind your posting is reading, you might blame yourself to be honest.
Programming is not chasing bugs, programming is avoiding bugs. Okay, not avoiding bugs actually, they sometimes simply occur because of complexity or changes, but being prepared for bugs is the first duty of every programmer, imho.
Could you have done better? Am I allowed such harsh words? I think so by reading your lines:
"...that it was using a struts action and almost all of the code was in the main method in the action..."
Why was all the code in the main method? Why didn't you create more methods (that could take parts of the code and be more easily debugged)? Why, if the code is too complex, didn't you create an own Object containing the code (this one really would be easy to debug)? Why didn't you simply write a "public static void main(String[] args);" which called the main method giving the right parameters to simply test this kind of code without restarting Tomcat every time? And I know this can work out, I used Struts, too ...
"...I have done a bit of refactoring but because it took me soooooo long to actually find..."
There is no such thing like "a bit of refactoring" - do it or leave it. And the chinese do have a saying: "If you are in a hurry, take your time. If you don't have time, get a detour."
"...I am only doing a bit and to be honest it works and it's an action, which is pretty much self contained so it's not that much benefit refactoring it..."
No benefit to refactor it, because "to be honest it works" ? Hm. Have a nice next-week chasing similiar errors...
"...especially when you are doing it like I was today by using logging messages. I must have wasted loads of time adding comments..."
Why were the comments and messages not already implemented? Inserting comments and debug-information afterwards takes presumably three to four times longer than thinking of them while programming-time. No, there is no runtime-issue on that, if you feel comfortable with it, you could simply comment them before the system goes productive. Heck, use "// @todo" - lines above them or something similar to mark them to be commented.
Yeah, all clear, you naturally don't have time to program like that, no one has. So go on to "...do get the feeling of restlessness..." and think you "...haven't really done much that day." .
Learn from the errors! Shaking the head, Georgi
By
Anonymous, at Wed Jun 07, 04:28:00 am 2006
I agree with your comments.
The reason most of the code is in the action is because I didn't write the code, I am merely debugging the code.
I think any refactoring helps no matter how small.
What I was trying to put across was the fact I haven't got time to refactor the code at the moment. It may cost me more time in the future but the project plan says I gotta start working on something else.
The comments were above and beyond the real need of comments except for debugging, it was printing out values every few lines within methods to see where they took a turn for the worse. It was really system out type values I was interested in.
Whether I could have written a tests using a main method, I suppose I could of. It would have meant creating initialising a couple of javabeans but in the long run this would saved me some time I think.
This I suppose is the joy of wrestling with some legacy code.
Thanks for your comment
By
The Hosk, at Wed Jun 07, 08:50:00 am 2006
Post a Comment
<< Home