by Darren Collins
Monday, 8 July 2002

Book Cover: Refactoring Refactoring: Improving the Design of Existing Code
by Martin Fowler
with contributions by Kent Beck, John Brant, William Opdyke and Don Roberts
464 pages, 1st edition (August 1999)
Addison Wesley Pub Co, ISBN 0201485672

Buy at

Sometimes, modifying old legacy code just seems too risky and requires too much time and effort. It's often badly written, and it's not obvious what it does (or what it's supposed to do, which may be something entirely different!). So what do you do if you really need to change it?

That's where Refactoring comes in. This book gives you the confidence, guidance and specific techniques you'll need to jump in and make those changes.

But its usefulness doesn't stop there.

It's easy to get bogged down in "analysis paralysis" when you're designing a class hierarchy for a new program. Should method A go in abstract base class X, or its subclass Y? What if you get it wrong? You know you'll be stuck with your design mistakes for years to come, so you want to be 100% sure you've got it right before you begin coding.

Because Refactoring helps you modify the underlying design of existing code safely, it means you don't have to come up with the perfect design before coding begins. You can jump in and start writing parts of your program very early in the development process, with the confidence that you can still redesign later if you need to. Early coding also gives you a practical feel for how your design works, and helps you identify design flaws or improvement opportunities before you've wasted too much time designing something impractical.

So what is this magical "refactoring"? Fowler defines it as:

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify, without changing its observable behaviour.

Refactoring contains a catalog of over 70 common refactorings, in much the same way that Design Patterns (Gamma et al) catalogs, well, design patterns. Each refactoring (with names like Move Method, Substitute Algorithm, and Rename Method) is illustrated with before and after code, and contains a checklist of the steps you need to go through when you make the change. This is a great idea, and it stops you from forgetting a step and introducing new problems.

All the example code in Refactoring is written in Java, but it is easily readable by anyone conversant in object-oriented design and development.

Fowler helps you to identify areas of the source code that are badly written and in need of refactoring by introducing the concept of "bad smells in code". These are things to look for that can make your code hard to understand and/or modify, but don't affect whether the code works correctly or not. They include things like long method functions, huge classes, duplicated code scattered throughout the program, and long function parameter lists.

In all, Refactoring describes 22 different "smells", and each description points you to one or more refactorings that might help you to remove the smell and improve the code.

The last few chapters of the book have been written by other developers at the forefront of refactoring research, and discuss things like adopting refactoring in a commercial environment and developing automated programming tools to support refactoring work.

Refactoring is one of those rare books that makes you stop and say "Oh". Keep it handy, 'cause once you start using it, you won't want to program without it!




Related Articles
- C++ FAQs: Frequently Asked Questions
- The Pragmatic Programmer
- Refactoring

General Programming Books

My Review

My Review

This site Copyright 1999-2005 Darren Collins.