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.
bignose : Right. Using behaviour-driven development, you write a new test for the behaviour and watch it fail, change the code so all tests pass, then refactor the code where you were working. *Then* commit, and (in your case) file the change against the behaviour-change request. That way, you refactor code while working on it anyway.From Outlaw Programmer -
The way we work it is: There must be a good reason to refactor the code, otherwise why?
If the reason is to allow another feature to use the same code, associate the changes with the other feature's request.
If it's to make something faster, create a feature request for faster 'xyz' and associate the changes with that - then the customers see you're improving the product.
If it's to design out a bug, log the bug.
It's worth noting that in my environment, the policy cannot be enforced. But clever managers can get reports of changes and if they don't have a bug\request reference in the commit text it's followed up.
From ColinYounger -
Lets have a look at each option:
- Write up a bug-report and associate the refactoring with it.
If you feel that, in your opinion, the original code poses a security risk or potential for crashing or instability. Write a small bug report outlining the danger, and then fix it.
- Write up a feature-request and associate the refactoring with it.
It might be harder to reactor code based on a feature request. But you could use valid feature request to do this which leads me onto the next point...
- Sneak in the refactorings while working on code that is associated with a bug-report/feature-request.
If there is a valid bug or feature, state that function x had to be change slightly to fix the bug or add the feature.
- Just don't do any refactoring.
This seems to suggest the self development through improving an application is not allowed. Developers should be allowed, if not, encourage to explorer new techniques and technologies.
- Other
Perhaps you could discuss your improvement at relevant meeting, giving convincing reasons why the changes should be made. Then at least you will have management backing to the change without having to sneak in the code through another method.
From GateKiller -
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.
From Anthony Williams -
- Other
If you work at a place with that kind of inflexible (and ridiculous) policy, the best solution is to find another job!
From Bob Nadler
0 comments:
Post a Comment