What refactoring is NOT

It can sometimes be helpful to explain what something is by saying what it is not.

Refactoring is not adding nor changing any functionality. The code should do exactly the same after any refactoring as before the refactoring. It should return exactly the same results, display exactly the same output, and react exactly the same to any input. Very often, if not almost always, refactoring is done as part of or as preparation for a change in functionality, but the refactoring itself does not change the functionality.

Refactoring is not about improving performance. Performance may or may not change due to a refactoring, but any such change in performance would be an incidental consequence rather than a direct aim of the refactoring. Of course, almost any change to the internal structure of a program will to some small degree change the performance of a program. If I divide a long method into two or three smaller methods, there will inevitably be some tiny change to the performance of the program. But any such performance changes are an inevitable side-effect of any changes to a program, including refactoring, rather than an objective, and in most cases are liable to be negligible.

Refactoring is not about stopping work for a few months to make a program in a good shape before carrying on; that can be done, but normally refactoring will be done as an ongoing task alongside normal development, just as a developer constantly tests his code, so a developer doing refactoring will be constantly doing refactoring.

Refactoring is not about ripping everything out completely, breaking everything and then trying to rebuild things with a hope that it’ll eventually be working again, but better. No. Refactoring is about moving from the existing program, and making single changes in small deltas so that at no stage is the program ever broken.

Refactoring is not like the car mechanic who completely strips down the engine into every tiny piece and then puts it all back together again. No. Refactoring is like the car mechanic who, while he happens to be working on a part of the engine on a task involving removing the spark plugs, will take a look at each spark plug in turn, checking the spark plug gap, replacing it in the engine, and checking each time that the engine still works correctly.

Refactoring is not about changing lots of things in a program at once. It is about changing one thing and only one thing at a time.

Refactoring is not about hacking into a change in a haphazard indiscriminate gung-ho approach with giant sweeping changes all at once. No, it’s about carefully making a single specific change in a series of small steps and testing after each step to ensure nothing has broken.

Refactoring is not about one programmer changing the work of another programmer to be in a style that he/she happens to like more. It’s about making changes which have real tangible improvements which, for the most part, can be objectively shown to improve the internal design of a program.

Refactoring is not only about big changes like extracting whole classes or breaking apart complex inheritance structures. No, refactoring is about even the simplest of changes such as replacing a magic number with a symbolic constant or introducing a temporary explaining variable to help clarify a complex expression, or simply renaming a method.

Refactoring is not only about tiny changes like renaming methods. It can be used to make giant changes to programs which truly turn upside down the way they work. Things like converting a program written in a procedural style to an object-oriented style, or restructuring a program to separate business logic from the presentation or user-interface layer.

And finally, refactoring is not about doing ‘busy’ work, with no real business value – something just to make the program look nicer or make the programmers feel good. No. Refactoring is about delivering real business value. It’s about making the program easier to change. It’s about making it easier and faster to add new functionality. It’s about reducing the likelihood of bugs and reducing the speed needed to find and fix them. It’s about extending the life of the program since it is more adapted to cope with the needs of the future. And while doing all of these things, there are even other unplanned bonuses which have real business value. Such as the program being more able to be redeployed for a variety of other tasks which were never part of the originally intended purpose. And such as the positive effect on team morale that people are working on a program of which they can be truly proud, rather than one of which they truly wish to see the back of.

See my book The Refactoring Workout for more on refactoring.