Question

On on hand:
1. You never get time to do it.
2. “Context switching” is mentally expensive (difficult to leave what you’re doing in the middle of it).
3. It usually isn’t an easy task.
4. There’s always the fear you’ll break something that’s now working.

On the other:
1. Using that code is error-prone.
2. Over time you might realize that if you had refactored the code the first time you saw it, that would have saved you time on the long run.

So my question is – Practically – When do you decide it’s time to refactor your code?

Thanks.

Answer 1

One of the most common mistakes i see is people associating the word “Refactor” with “Big Change”.

Refactoring code does not always have to be big. Even small changes such as changing a bool to a proper enum, or renaming a method to be closer to the actual function vs. the intent is refactoring your code. With the exception of the end of a milestone, I try to make at least a very small refactoring every single time I check in. And you’d be amazed at how quickly this makes a visible difference in the code.

Bigger changes do take bigger planning though. I try and schedule about 1/2 a day every two weeks during a normal development cycle to tackle a bigger refactoring change. This is enough time to make a substantial improvement to the code base. If the refactoring fails 1/2 a day is not that much of a loss. And it’s rarely a total loss because even the failed refactoring will teach you something about your code.