Archive for October, 2014

Refactoring: You Keep Using that Word, I Do Not Think It Means What You Think It Means

“Refactoring,” as a term, is rapidly becoming meaningless. The final nail in the coffin, for me, was this morning when I heard a sales guy say:

I need to refactor the pipeline in Salesforce—it’s got a bit messy and needs tidying up.

When a term has become so generic that sales guys start (mis-)using it, it’s lost all value.

He’s not alone. I’ve lost count of how many times I’ve heard software engineers who should know better say “refactoring” when what they actually mean is “changing.”

Refactoring (actual refactoring, not redesigning, reimplementing, debugging, …) is one of the biggest advances in software development over the last couple of decades. It is the process of improving the design of existing code without changing its behavior. It relies on two key insights:

  • Modifying existing code can be carried out safely only with the safety net of a comprehensive suite of tests.
  • We should never attempt to refactor the code at the same time as modifying its behavior.

In other words, you can modify the behavior of the code, or you can refactor it. You should never attempt to do both at the same time.

Upon reflection, it’s easy to see why this is the case. Imagine that you attempt to modify both the structure of your code and its functionality at the same time, and after doing so one of your tests fails. This might indicate that you made a mistake when modifying its structure. Or it might be an expected result of the change in functionality. It’s difficult, however, to be sure which. The more complicated the change in functionality or structure, the harder it is to be certain.

By doing only one or the other, you avoid this issue entirely and can forge ahead with potentially far-reaching refactorings involving dramatic changes to the code with confidence.

I fear that it’s too late; “Refactoring” is used incorrectly so often that it’s probably beyond rescue. But I hope not.