Refactoring - small steps is the key

Whenever we do refactoring, we try and make the changes in steps, and steps which are as small as reasonably possible.

Some people when they think of refactoring think of it as if it were a complete mini-rewrite of a part of the code – rip everything out and redo it better. No! No! No! We identify a single clearly defined change which we want to make to the program – like extracting a method or creating a parent class – and we do this change in a series of very small steps, making very small changes to the code, testing after each small change, and we repeat this until the series of small steps is complete and we arrive with our single clearly defined change complete.
The idea is that if we make our change in small steps we are both less likely to actually make mistakes in the process, but also, if we do make a mistake, it is much more likely to be instantly apparent, easily fixable and small.
By contrast, if we make a whole bunch of changes to code all at once, then it is very easy to introduce all sorts of bugs which we would not easily notice when we test.

The idea is to do each refactoring in steps almost so small that even a complete programming dolt would not make a mistake. The fact that I actually do make mistakes when refactoring shows just how essential this is. Or maybe it shows I am a programming dolt? Whatever the real case is, each of us makes mistakes, and the smaller the change, the smaller the chances of making one. Refactoring is not about changing a program in a random ad-hoc manner; it is about changing a program in as disciplined and organised way as possible so that bugs have as little chance as possible to creep in. Taking small steps is a key part of that discipline.

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.