Refactoring: Improving the Design of Existing Code [Hardcover]

Refactoring refers to taking existing, working software, and changing it about to improve its design, so that future modifications and enhancements are easier to add. _Refactoring_ is primarily a catalog of 70 or so different kinds of improvements you can make to object-oriented software.

Each entry in the catalog describes an implementation problem, the solution, motivation for applying the solution, the mechanics of the refactoring, and examples. The book's examples are all in Java, but C++ programmers should be able to approach the refactorings with ease. Often, Fowler diagrams the refactorings in UML, so a little Unified Modeling Language experience will help, too.

While the catalog is nice, the kinds of refactorings are obvious is most cases. Even moderately experienced programmers won't need the step-by-step mechanics described. The real benefit, though, is that the mechanics of each refactoring help guarantee that you can pull off the refactoring without introducing new bugs or side effects. They encourage you to take smaller, verifiable steps, than the more gross refactorings that most developers would naturally take. You actually save time doing so.

How do you know your refactorings are safe? Unit testing is the answer that Fowler et al. provide. Java developers will find the introduction to the Junit Testing Framework the most valuable part of the book, more so than the catalog of refactorings itself.

There's more to the book than the catalog and Junit, of course. There's discussion of the history of refactoring, how to evaluate refactoring tools, and how to convince management that what appears to be an overhead activity is actually useful in the long run.

Unfortunately, these sections are all too brief. And there is no discussion of how refactoring fits in with various software development processes. For example, programmers using Extreme Programming (XP) would probably feel right at home with Fowler's recommendations of refactoring in duets and unit testing, but developers stuck with a Software Engineering Institute process like PSP categorize testing as failure time and something to be minimized if not avoided. Cleanroom developers are taught that unit testing inteferes with metrics for quality, and that verifications are what should be done. Should such developers redo verifications after each refactoring? There's no answer in this book.

An unusual chapter, called "Bad Smells in Code," gives overall motivation for the refactorings. These vague notions, such as "long methods" or "lazy classes" humorously provide a foundation for starting your own refactorings. I say "humorously" because (mostly) Beck's and Fowler's odd analogies (classes becoming too intimate and delving in each others' private parts) provoke a chuckle (as if a chapter about "bad smells" in code weren't enough).

Overall, I've enjoyed reading this book and referring to the catalog while putting my own unit tests and refactorings into practice. Fowler's writing style is smooth and fluid, and it's easy to digest the catalog in no time. The book's typesetting is crisp, the figures quite clean, and both the refactoring index and "smell" index are enormously useful.