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 try to refactor on a piecemeal basis. That is, when I need to add new functionality, I refactor it in such a way that makes it easier to add that functionality in first. This makes refactoring a slower process, but it tends to make for an easier time adding changes.

Answer 2

Oftentimes refactoring can reduce or eliminate the need to do the real work assigned. If you're fixing a bug then refactoring is a good place - assuming there's tests in place. To a lesser extent adding new features can be achieved with a simple refactoring of the code to make it a bit cleaner or more efficient and then you see that the feature was already there and how to get the user to enable it.

The short answer, however, is that you don't refactor code that works unless there's a pressing need. A good checklist is:

• Am I going to be working with this code daily for an extended period AND am I the ONLY person who will be.
• Is the code so bad that it can't be properly understood. Usually I find I'm just suffering from a case of not invented here syndrome (the thing where someone else's perfectly good solution isn't how I would have done it so I want to do it again for no real gain except pride).
• Is the architecture not capable of supporting said new work (feature, bug fix, etc).
• Is the code so incestuous that changing a few small things has a massive ripple effect of follow-on bugs.

If you answer yes to any one of those then it might be time to refactor.

Answer 3

I agree, it's tempting but if you focus on it you might not get any of your real work done!

Two suggestions:

1. Mark the code so that you can go back to it later to clean up (use the TODO comment or something similar)
2. Add a bug to your bug tracking system indicating smelly code. Perhaps you can then get time scheduled to fix a group of them.

Answer 4

The answer is you don't. Just because code works doesn't mean it will always work. Bad code is bad code.

We refactor to make the code more readable, easier to maintain, and to ensure reliability.

As long as you keep the logic of the old code, it should still work, plus have the added bonus of being overall better code.

I always try to leave code better than I found it.

Answer 5

Perfectly valid question.

I use to find myself starting to refactor code automatically as I ran into it. When I'm 5 minutes or so into the operation (checking things out etc) I suddenly get this feeling that what I'm doing is going to take longer than I expect. At this point I ask myself, is it worth the effort going down this rabbit hole? To be honest, it sometimes is, but most of the time it's not, and after a while you realize you want to rewrite the whole system, just while you're at it!

This got me into the habbit of asking myself continuously: Is the code I'm writing now going to help me accomplish this task in a reasonable amount of time? Am I "wasting" the company's time by doing this refactoring while there are outstanding items which are much higher on the priority list?

I've seen programmers that don't even realize they're doing it. They will work for days on end to get the code in a state where they feel they can now start implementing new features or perform bug fixes. They can't distinguish between refactoring and spending time on the assigned issue.

What I do is just comment what I want to do later on, and simply work with the existing system, no matter how ugly it is! This allows me to break less things and actually getting through my list of things to do much quicker. (We don't do TDD... yet)

Once you find the time, come back and refactor.

Answer 6

"Refactoring existing code that works" - This is obviously a minority opinion here, but this is a complete waste of time. It is good you are attempting to restrain yourself.

If you think the code is so bad, find a non-trivial bug in it before you refactor it. Then add an automated test for that bug. Only then allow yourself to refactor.

The attitude that after refactoring working code "I've left the code better" is often programmer hubris. In many cases you don't really know you left the code better, you just believe you did. If you didn't even fix a bug or add functionality why take the risk of being wrong?