Refactoring - One change at a time

When we do software refactoring, we just make one change at a time. Not a whole bunch of little changes, but one single well-defined change. You’re maybe tempted to make a whole bunch of changes at once. No! One I said! One single change! That’s all. I know, you want to change a number of things, but you are only going to change one. But patience: later, maybe only a few minutes later, you will change the next. So you can make a whole bunch of changes, but you simply make them in sequence, one at a time.

So what constitutes a single change? A single change is any individual change which upon completion leaves the code internally in a better state. It can be anything from the renaming of a local variable to something clearer, to a difficult breaking up of a single class into a complete hierarchy of smaller subclasses.

Though I hope it does not need saying, I will say it anyway, by one change at a time I do not mean that the code actually does anything different at the end of the change. No, as you will well remember, refactoring, at the very core of the definition, says that there is absolutely no change in what the program actually does. The code will have absolutely identical functionality at the end of the change as at the start of the change. The change is to the clarity of the code, or the structure of the code, not to the functionality of the code.

For example, if our code was a mathematical equation, it would start perhaps by saying 4+3+7+6 = 20 (is this true or not? Hmmm...who knows – maybe we could refactor it to make it clearer), then after the change it would say 5+5+5+5=20 (ah! That’s clearer! Now I can see how it works!) – the value at the start and the end, the ‘20’ of the result, is the same, so there is no change in the functionality, but what has changed is the way in which it was calculated. Refactoring always keeps the result the same, but changes the way in which it is done to make it clearer. Anyway, I’m sure I didn’t need to tell you that by change, I mean a change that doesn’t change anything, since you remember that part of the story, but I thought I’d remind your slightly less attentive colleague.

See my book The Refactoring Workout for more on refactoring.