Tracking Refactorings in a Bug Database

Question

Let's say you work someplace where every change to source code must be associated with a bug-report or feature-request, and there is no way to get that policy reformed. In such an environment, what is the best way to deal with code refactorings (that is, changes that improve the code but do not fix a bug or add a feature)?

• Write up a bug-report and associate the refactoring with it.
• Write up a feature-request and associate the refactoring with it.
• Sneak in the refactorings while working on code that is associated with a bug-report/feature-request.
• Just don't do any refactoring.
• Other

Note that all bug reports and feature descriptions will be visible to managers and customers.

Answer 1

I vote for the "sneak in refactorings" approach, which is, I believe, the way refactoring is meant to be done in the first place. It's probably a bad idea to refactor just for the sake of "cleaning up the code." This means that you're making changes for no real reason. Refactoring is, by definition, modifying the without the intent of fixing bugs or adding features. If you're following the KISS principle, any new feature is going to need at least some refactoring because you're not really thinking about how to make the most extensible system possible the first time around.

Answer 2

If you're working on a block of code, in most cases that's because there's either a bug fix or new feature that requires that block of code to change, and the refactoring is either prior to the change in order to make it easier, or after the change to tidy up the result. In either case, you can associate the refactoring with that bug fix or feature.