How do you stop yourself from refactoring working-

Question

I have this problem. I can't stop myself from refactoring existing code that works but is, in my opinion (and perhaps objectively), badly designed or contains other "code smells". This can have a significant negative effect on my immediate productivity. But ultimately will be a big maintenance boon.

If you also suffer from this "affliction", how do you restrain yourself? Or at least manage the refactoring to avoid having to alter large chunks of existing code in order to make it maintainable for the long term.

Answer 1

I generally don't touch any legacy code UNLESS I am asked to build on it extensively. If the code is so bad that adding one feature cascades into bugs all over the place, you have a real reason to re-engineer it.

In addition, there is a very, very real risk you will introduce bugs that had been fixed in the legacy mess. That will make you look unprofessional.

The only good way, IMO, is to slowly refactor the old code outside of production. Then, when you think the functionality is the same, go through the old resolved bugs and make sure no old bugs show up again.

Roll it out to QA and brag to management about it, preferably with some cool new feature or two. If the new code performs much faster, that's a definite selling point.

Generally you will have two issues: complete lack of time, and management pushing against allocating time to refactor. If none of those are an issue, consider yourself very lucky.

Edit: Joel Spolsky has the best answer, I believe.

Answer 2

If I'm working on a task, I don't let anything get in the way of it - it is too easy to get carried away. Anything that looks like it needs work then it probably does, but maybe not right away - make a note/add it to your bug tracker.

Answer 3

I read the old Uncle Remus story about the Tarbaby. Or I bring out one of those signs from the stores where it says "You Touch It, You Own It".

Answer 4

I create an issue in our issue tracker (or you could use a post-it note) about fixing that code, and then forget about the problem.

This allows everyone to know that there is code that is bad that could cause some problems, but also allows me to keep working on my current task without too many distractions.

Answer 5

I suffer from refactoritis as well, and I deal with it by directing it at code that is mine that others have maintained or other people's code that I have to maintain. And by deal with it, I mean "check version control every hour on the hour to see if anyone has touched my code and if they did, do an immediate diff."

Answer 6

I usually don't restrain myself. If I find a bad piece in the code I'm working on, I correct it directly.

I'm working on a software that has been maintained for about 10 years now and will have to work at least ten more years. In such a situation, the longer a code smell stays in the code, the more often my fellow developers and I will stumble over it and waste time trying to figure it out or invent workarounds for it. This costs more money than just doing the work right now.

An exception are large design problems that take days to refactor. If those do not obstruct my current project in a significant way, I add it to our maintenance todo list to work on the refactoring as a planned task in the near future.