Next up on the “Must Read” list is the follow-up book from Martin Fowler of the Gang of Four, Refactoring: Improving the Design of Existing Code. I hesitated with this one for a bit, thinking about adding it to the “Should Read” book list rather than the “Must Read.” I did this because, for many experienced developers, the topics of this book are going to seem elementary. Anyone decently experienced is going to look at a section header such as “Changing a Reference object to a Value object” and think “why I am even wasting my time with this Programming 101 refresher?” But, much like Design Patterns, the fact that much of the information in the book has already been deduced through a combination of ingenuity and experience does not mean that the refresher cannot be extremely valuable. And not ruffle any feathers, but usually the people that are most dismissive of “refresher” material are exactly those that need it the most! <g>
At the very least, this book is an encyclopedia of these changes, and while many or most of the changes will be elementary, even the sections on those changes might have a new insight or viewpoint that the developer has not considered. Chapter 3, which I’ll discuss below, is particularly useful here. Another benefit is that any development manager or mentor of younger developers would be well-served to be familiar with this book so that they can point their less experienced colleagues to the proper place to learn how to correct mistakes they have made.
Like Design Patterns before it, this book is about more than just specific techniques for one language. The advice for guidelines and techniques in this book can be applied across all object oriented programming. It’s a common viewpoint to dismiss refactoring as a problem that you only encounter in projects involving legacy systems. That’s not really the case, though, as it is common to see these types of problems in daily work when interfacing with different systems, reviewing the work done by less experienced developers, etc.
The first 50 pages are a good introduction to draw someone in, as it provides a walkthrough of a standard refactoring problem. This is a great read for the inexperienced programmer, as it can be an enlightening view into the daily problem solving in the lives of senior developers and architects. The next chapter makes a case for refactoring, which can be interesting for some, but doesn’t hold a candle to Chapter 3. Chapter 3 is 20 pages of gold, as it examines the “Smell” of problems in need of refactoring. When confronted with a specific problem, it’s easy enough to know the solution. This chapter focuses on how to identify problems that are present. This is really a brilliant piece of writing, in that it is clear cut, with obvious warning signs on what to recognize to diagnose the problem.
The next chapter, Building Tests, focuses on an area that we frequently don’t do enough of. It focuses on JUnit, but the testing focus, as with the patterns and coding elsewhere, can be applied to other languages. The other chapters, again, exactly like Design Patterns, group the common techniques and problems into common areas and then proceed through each of them in a very straightforward matter. At the very least, the book makes a fantastic reference to keep around and to thumb through when you run into problems you can’t quite put your finger on, or when you’re just looking for a great refresh of some standard material.