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.
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.