When to refactor

Question

I've read through most of Fowler's Refactoring book and have refactored many applications in my past big and small.

One of the harder things I find to teach is "when" to refactor. I tend to do this based on a gut feel which has served me remarkably well in the past. However, when getting into discussions with people about whether a piece of code should be left alone or refactored right now it is hard to stand by the "gut check".

I feel like there should be more rigorous approaches to this, but am not sure what they are.

I understand "code-smells", red-green-refactor and other thoughts, but often I feel that the best time to refactor is not the first time you write the code, but the second or third time you are using the code and realize that it is actually a problem and is in actual use.

Answer 1

Refactor when the cost of refactoring is less than the cost of not refactoring.

Measure "cost" however you can. For example, is the code so poorly implemented that trivial bugs cost hours or days to fix? Will refactoring allow you to gain more customers, or increase capacity, or improve performance and thus make your existing customers happier?

Answer 2

1. Is the cyclomatic complexity of the function below 5?
2. Did you completely understand what cyclomatic complexity was without following that link?
3. Do you have an automated test or documented test case for every path through the function?
4. Do all of the existing test cases pass?
5. Can you explain the function and all it's edge cases to me in less than 1 minute?
6. If not, how about 5 minutes?
7. 10 minutes?
8. Are there fewer than 100 lines of code in the function (including comments)?
9. Can you find two other developers who agree this code is error free just by visual inspection?
10. Is this function used in only one place?
11. Does the function meet it's performance goals (Time/Memory/CPU)?

Scoring

Add up the "no" answers above:

• 0-1 - Why would you even think about refactoring this? You probably just want to rename variables because you don't like the previous developer's naming convention
• 2-5 - This might need a little tweaking, but I wouldn't hold up a production release for something in this range
• 6-8 - OK, we probably need to fix this... It's likely we're going to keep revisiting this and/or we don't actually know what it's doing. Still on the fence, but it's highly suspect
• 9+ - This is a prime candidate for refactoring. (Note, writing test cases is a form of refactoring)

http://mikemainguy.blogspot.com/2013/05/when-to-refactor-code.html

Answer 3

When your gut is telling you that you should probably do some refactoring, It's likely it's your instincts telling you a little late that you've been putting something important off for too long.

I understand "code-smells", red-green-refactor and other thoughts, but often I feel that the best time to refactor is not the first time you write the code, but the second or third time you are using the code and realize that it is actually a problem and is in actual use.

There are effectively two levels to refactoring. The first is the obvious issues that appear when you first code. These are the little optimizations that cost you very little to do up front. Things like keeping your methods and classes small, and adhering to DRY and SRP. Then you have the additional stage of dealing with major flaws in your design, which may not be immediately apparent until your code has a couple of miles under it. It's this second level that you are talking about, and yet in order to ensure that later refactoring isn't too costly, you need to have already written your code in such a way that the effort you later envisage is made easier and less costly, which means doing an early refactoring.

As Jeff mentioned in his answer, "time is money", particularly in companies where the workload is high and the risks even higher. Time spent up front making sure the code is in its best possible state is time saved later, when teasing out what should have been an easy refactoring turns out to be a major operation.

When writing software, every moment spent improving your code up front is time saved later, when you're really going to need it. The earlier you refactor, the clearer your later changes will be. It's like making a down payment in today's dollars against future technical debt which will be in tomorrows inflated dollars.

In any case, refactoring shouldn't be a task that you put off until some mysterious future when the software is already complete and stable, as it increases your risks later when the stakes are much higher and the product much more difficult to change. Refactoring should be a part of your daily activities, and this is the essence of the Red-Green-Refactor philosophy that you mentioned.

Answer 4

I think your question can be answered differently by each developer and even the management in charge of the programming.

My personal preference is, whenever I learn something new, or improve my best practices, I refactor the code that I can - I like to keep my code up to standard as soon as I learn what the best standard to use for that situation was. I am allowed to do this though because it is a smaller company that uses the same software for long periods of time.

In a bigger software development company where time is money, it may be to just start designing with the better practices you learned from this point forward, do not worry about refactoring until verison 2 of that specific software?

I feel teaching when to refactor really depends on the company you are currently in.

Answer 5

"When to refactor ?"

Short answer : every time you come across code that smells bad or could be improved (Boy Scout Rule)

Practically, this happens :

• If you practice TDD, systematically during the Refactor step of the TDD cycle, that is, once your test is green and before you start writing a new test.
• As a result of a code review
• When taking over legacy code
• When consuming code that seems awkwardly designed
• etc.

Answer 6

When I was first learning about refactoring, my mentor told me: "Do it twice, hold your nose. Do it three times. refactor." (Thanks, Josh!) To be specific, what he was saying was that when you are about to write the same block of code for the third time (or even a similar code pattern), that is the time to refactor. I have followed that for the past 10 years, and found it to be a sound enough rule of thumb.

Using Eclipse, or similar IDE which has strong refactoring support, reduces the effort to do the refactoring. The IDE support makes it more likely you will refactor as soon as you hit the "third time" (or see the need), instead of seeing it as additional effort.

Also - TDD is a big help here too, since you can keep running your tests as your refactor, and know that you haven't broken anything.

Answer 7

Refactoring by its definition is a process. This implies that you should not strive to find spare time to do the rafactoring task, instead you should keep refactoring all the time when you come across code code that could be written better.

Personally I like writing evolutionary prototypes, saying it more simply: code that just works, and then refactoring those until they will meet expected coding standards. Another good example is adding additional functionality and refactoring existing code to enable its reuse.

Answer 8

In my 20 years of programming, here is the only rule of thumb that I've actually seen work, which people can stick to, and managers allow time for. (Refactoring is like dieting: sure, "calories in / calories out" is the formula to losing weight, but that doesn't translate into a diet that people will comply with.) And so:

Refactor continuously, as you work. Use Test Driven Development so that you have several red-green-refactor cycles through the day. Refactor just the parts of the code that you've touched.

Once you're more sure of yourself, you can vary from this regimen.

Answer 9

I think, that depends on the demands of the project owner and the guy that answers for the quality of the code. You simply can't decide it alone, when the money of somebody else are under question.

As for technical reasons, there are several.

• If you have a bug in the code, that means that this place is misunderstood and it is VERY probable that more errors could be hidden here and surely there will be great problems with any attempt to develop the connected parts of code. So, this place should be checked for possible refactoring.
• Another reason is when you add or change a feature and the old code is very inconvenient for changing/adding and the later changes/addings are highly possible. Of course, you should balance the cost.
• Maybe the most serious reason is when you are changing the code and it is untestable.