How often should you refactor?

Question

I had a discussion a few weeks back with some co-workers on refactoring, and I seem to be in a minority that believes \"Refactor early, refactor often\" is a good approach t

Answer 1

Everytime you encounter a need. At least when you're going to change a piece of code that needs refactoring.

Answer 2

Continuously, within reason. You should always be looking for ways to improve your software, but you have to be careful to avoid situations where you’re refactoring for the sake of refactoring (Refactorbation).

If you can make a case that a refactoring will make a piece of code faster, easier to read, easier to maintain or easier or provide some other value to the business I say go for it!

Answer 3

Three good reasons to refactor:

• Your original design (perhaps in a very small area, but design nonetheless) was wrong. This includes where you discover a common operation and want to share code.
• You are designing iteratively.
• The code is so bad that it needs major refurbishment.

Three good reasons not to refactor:

• "This looks a little bit messy".
• "I don't entirely agree with the way the last guy did this".
• "It might be more efficient". (The problem there is 'might').

"Messy" is controversial - there is a valid argument variously called "fixing broken windows", or "code hygiene", which suggests that if you let small things slide, then you will start to let large things slide too. That's fine, and is a good thing to bear in mind, but remember that it's an analogy. It doesn't excuse shunting stuff around interminably, in search of the cleanest possible solution.

How often you refactor should depend on how often the good reasons occur, and how confident you are that your test process protects you from introducing bugs.

Refactoring is never a goal in itself. But if something doesn't work, it has to be fixed, and that's as true in initial development as it is in maintenance. For non-trivial changes it's almost always better to refactor, and incorporate the new concepts cleanly, than to patch a single place with great lumps of junk in order to avoid any change elsewhere.

For what it's worth, I think nothing of changing an interface provided that I have a handle on what uses it, and that the scope of the resulting change is manageable.

Answer 4

As the book says, You refactor when

• you add some code... a new feature
• when you fix a bug / defect
• when you do a code-review with multiple people
• when you find yourself duplicating something for the third time.. 3 strikes rule

Answer 5

Refactor opportunistically! Do it whenever it's easy.

If refactoring is difficult, then you're doing it at the wrong time (when the code doesn't need it) or on the wrong part of the code (where there are better efficiencies to be gained elswhere). (Or you're not that good at refactoring yet.)

Saving refactoring for "maintenance" is a tautology. Refactoring is maintenance.

Answer 6

"Refactor early, refactor often" is a productive guideline. Though that kind of assumes that you really know the code. The older a system gets, the more dangerous refactoring becomes, and the more deliberation is required. In some cases refactoring needs to be managed tasks, with effort level and time estimates, etc.