Refactoring is the process of changing a software system in such a way
that it does not alter the external behavior of the code yet improves its
internal structure.” — MartinFowler inRefactoring Improving The Design Of Existing Code
Refactoring is typically done in small steps. After each small step, you’re left
with a working system that’s functionally unchanged. Practitioners typically interleave
bug fixes and feature additions between these steps. So refactoring doesn’t preclude changing
functionality, it just says that it’s a different activity from rearranging code.
The key insight is that it’s easier to rearrange the code correctly if you don’t simultaneously
try to change its functionality. The secondary insight is that it’s easier to change functionality
when you have clean (refactored) code.
A popular metaphor for refactoring is cleaning the kitchen as you cook. In any kitchen in which
several complex meals are prepared per day for more than a handful of people, you will typically
find that cleaning and reorganizing occur continuously. Someone is responsible for keeping the dishes,
the pots, the kitchen itself, the food, the refrigerator all clean and organized from moment to moment.
Without this, continuous cooking would soon collapse. In your own household, you can see non-trivial
effects from postponing even small amounts of dish refactoring: did you ever try to scrape the muck f
ormed by dried Cocoa Crispies out of a bowl? A missed opportunity for 2 seconds worth of rinsing can
become 10 minutes of aggressive scraping.
Refactoring Automation in IDEs
Refactoring is much, much easier to do automatically than it is to do by hand. Fortunately, more and more
Integrated Development Environments (IDEs) are building in automated refactoring support. For example,
one popular IDE for Java is eclipse, which includes more auto-refactorings all the time.
To refactor code in eclipse or IDEA, you select the code you want to refactor, pull down the specific refactoring
you need from a menu, and the IDE does the rest of the hard work. You are prompted appropriately by dialog boxes
for new names for things that need naming, and for similar input. You can then immediately rerun your tests to
make sure that the change didn’t break anything. If anything was broken, you can easily undo the refactoring