The mere act of fixing a bug is not enough, Gérald argues. You must do more, answer other questions that will help the people coming after you determine why the bug was a bug, what the fix was, why that fix was chosen, etc.
What version of the app did you find this bug in?
What environment does the bug occur in? Production? On your local machine? Somewhere in between?
How easy was the bug to reproduce? What were the steps?
Did any of the app's dependencies come into play? Are they obsolete? Do you have them?
Is the project easy to get started on? Could an experienced programmer, with no knowledge of this app, get started working on it fairly quickly?
Where are the tests? Do they work?
Frankly, there's a lot to consider when fixing a bug. But we need to do so, because we want to make it easier on the next person who has to find a similar bug, which just might be us.
So, what do we do? We implement good debugging rules, which could include:
Pair programming or code reviews. Sometimes two eyes are better than one!
Turning on strict options for our compiler, such as treating warnings like errors.
Taking great care to prevent breaking changes, particularly in shipped APIs.
Fuzz testing, which takes randomly generated bad inputs and feeds them to a program, hoping to cause bugs.
Incidentally, this article reminded me of one of my favorite programming quotes:
"Everyone knows that debugging is twice as hard as writing a program in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -Brian Kernighan
This article is for paying subscribers only
Sign up now and upgrade your account to read the article and get access to the full library of articles for paying subscribers only.