When is it time to refactor code?

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

A couple of observations:

On on hand: 1. You never got time to do it.

If you treat re-factoring as something separate from coding (instead of an intrinsic part of coding decently), and if you can't manage time, then yeah, you'll never have time for it.

1. "Context switching" is mentally expensive (difficult to leave what you're doing in the middle of it).

See previous point above. Refactoring is an active component of good coding practices. If you separate the two as if they were two different tasks, then 1) your coding practices need improvement/maturing, and 2) you will engage in severe context switching if your code is in a severe need of refactoring (again, code quality.)

1. It's usually isn't an easy task.

Only if the code you produce is not amenable to refactoring. That is, code that is hard to refactor exhibits one or more of the following (list is not universally inclusive):

1. High cyclomatic complexity,
2. No single responsibility per class (or procedure),
3. High coupling and/or poor low cohesion (aka poor LCOM metrics),
4. poor structure
5. Not following the SOLID principles.
6. No adherence to the Law of Demeter when appropriate.
7. Excessive adherence to the Law of Demeter when inappropriate.
8. Programming against implementations instead of interfaces.

1. There's always the fear you'll break something that's now working.

Testing? Verification? Analysis? Any of these before being checked into source control (and certainly before being delivered to the users)?

On the other: 1. Using that code is error-prone.

Only if it has never tested/verified and/or if there is no clear understanding of the conditions and usage patterns under which the potentially error-prone code operates acceptably.

1. Over time you might realize that if you would have refactored the code the first time you saw it - That would have save you time on the long run.

That realization should not occur over time. Good engineering and work ethics calls for that realization to occur when the artifact (being hardware or software) is in the making.

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

Practically, when I'm coding; I detect an area that needs improvement (or something that needs correction after a change on requirements or expectations); and I get an opportunity to improve it without sacrificing a deadline. If I cannot re-factor at that moment, I simply document the perceived defect and create a workable, realistic plan to revisit the artifact for refactoring.

In real life, there will be moments that we'll code some ugly kludge just to get things running, or because we are drained and tired or whatever. It's reality. Our job is to make sure that those incidents do not pile up and remain unattended. And the key to this is to refactor as you code, keep the code simple and with a good, simple and elegant structure. And by "elegant" I don't mean "smart-ass" or esoteric, but that displays what is typically considered readable, simple, composable attributes (and mathematical attributes when they apply practically.)

Good code lends itself to refactoring; it displays good metrics; its structure resembles both computer science function composition and mathematical function composition; it has a clear responsibility; it makes its invariants, pre and post-conditions evident; and so on and so on.

Hope it helps.

Answer 2

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.