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.