by Martin Fowler with contributions by Kent Beck, John Brant, William Opdyke, and Don Roberts
Addison-Wesley Pub Co

A little while back I was introduced to a word I had never heard before, Refactoring. I was told to get Martin Fowler’s book and read it so I could gain a better understanding of what Refactoring was. Well folks, I would classify this book as a ‘Hidden Treasure’.

Although it is not a flashy or well known title, I believe its impact can be much deeper and long lasting than many of the mainstream, more popular technology books. The underlying theories that it teaches can be applied for years, even when technology changes.

There are only a couple of things I would change about this book, which I will mention below.

Preface
The Preface it brief enough, and gives the definition for the word Refactoring. This is a good thing because right form the start you get the true definition of Refactoring. In short, refactoring is the process of changing code to improve the internal structure, but not changing the external behavior.

Chapter 1: Refactoring, a First Example
In this chapter Mr. Fowler tries to start by showing a simple Refactoring example. The problem is that the chapter then goes on for 50+ pages. Mr. Fowler explains his reasons for doing this, but I think that a simple example should have been much simpler. Especially when it is in the first chapter of the book. It’s not that this isn’t a good chapter. I feel it’s just too soon in the book. I would have put it at the end.

Chapter 2: Principles of Refactoring
This is an excellent chapter. The definition of Refactoring is discussed as well as the following questions: Why should you refactor? When should you refactor? What do I tell my manager? This last question may seem funny, but when you read this chapter you will understand why it is in there. This chapter also discusses common problems that occur during Refactoring, and Refactoring and performance.

Chapter 3: Bad Smells in Code
In this chapter things that cause code to ‘smell’ are discussed. When code ‘smells’ it could be an indicator that refactoring is needed. 22 different ‘smells’ are discussed. My favorites were Duplicated Code, Large Class, and Lazy Class. This is a chapter full of awesome hints.

Chapter 4: Building Tests
Building tests is an important part refactoring. Refactoring is done in small steps, and after every step you should test. In this chapter the discussion covers the processes and methodology of applying tests during refactoring.

Chapter 5: Toward a Catalog of Refactorings
This chapter is a quick setup for chapters 6 to 12. Mr. Fowler explains his method for cataloging the individual refactorings. What is pretty amazing is that he has taken a lot of time naming and detailing each refactoring.

Chapter 6: Composing Methods
One of my favorite chapters. Mr. Fowler opens by saying, “A large part of my refactoring is composing methods to package code properly.” This chapter is all about that. 9 total refactorings are explained. My favorite ones are Inline Method and Extract Method.

Chapter 7: Moving Features Between Objects
Sometimes you need to move things from one object to another. This chapter discusses the art of moving features between objects. 8 total refactorings are discussed and detailed. My favorite from this chapter is Extract Class.

Chapter 8: Organizing Data
A very large chapter that discusses in meticulous detail 16 refactorings that will make it much easier to work with data. One thing that becomes very obvious in this chapter is that certain refactorings can go either way. What I mean is illustrated by these two: Change Value to Reference and Change Reference to Value. So some refactorings are not just one way deals. It just depends on the situation.

Chapter 9: Simplifying Conditional Expressions
This is a very useful chapter since conditional logic is a common occurrence in the programming world. Because conditional logic has a tendency to get very complex, this chapter has 8 refactorings that will help you simplify things.

Chapter 10: Making Method Calls Simpler
The 15 refactorings in this chapter help teach us how to make method calls easier to deal with. They range from the very simple Rename Method to the more complex Replace Constructor with Factory Method.

Chapter 11: Dealing with Generalization
Here are 12 refactorings dealing with the situations that arise from generalization. Inheritance, Delegation, and Interfaces are some of the topics discussed.

Chapter 12: Big Refactorings
Kent Beck co-wrote this chapter with Mr. Fowler. They discuss what they call the 4 Big Refactorings: Tease Apart Inheritance, Convert Procedural Design to Objects, Separate Domain from Presentation, and Extract Hierarchy. These refactorings are of a more all-encompassing type than the smaller individual refactorings from the preceding chapters. The co-authors do a great job at putting in a nutshell what would normally take very long explanations.

Chapter 13: Refactoring, Reuse, and Reality
William Opdyke writes this chapter. He discusses his experiences with refactoring as well as other subjects like why developers are reluctant to refactor and reducing the overhead of refactoring. This chapter is an excellent ‘putting it all together’ chapter, and really helps put into perspective the ideas that the book teaches.

Chapter 14: Refactoring Tools
Don Roberts and John Brant co-author this chapter. They discuss, as the chapter title would indicate, refactoring tools.

Chapter 15: Putting It All Together
Kent Beck gives a quick 4-page wrap up.

One other thing I would change about the book is that I would want there to be examples in other languages besides Java. I have practically no Java skills. For me the book would have been an easier and faster read if it would have had examples in VB.net. Fortunately I understand enough to get the idea of what is being taught, and that is the most important point.

Well as I said above, this book is really what I would consider a ‘hidden treasure’. The things discussed will help many people write better, more understandable code for years to come. I would give it a 9.5 out of 10. It is well worth the price.