This is the essential refactoring book, and one that I read much later than I should have done.

I’d done some reading on refactoring, of-course, but it was limited and mainly based around what changes classified as refactoring vs which ones were a re-write (though now I know that anything that’s not covered in this book is a re-write).

The book starts off with an introduction to the topic of refactoring, then provides an example of refactoring some messy code, to both introduce some of the concepts and explain the format of the book.

The topic of refactoring is closely tied with that of testing, and this book addresses this early and often, this quote appears in one of the first chapters of the book: > “Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code” This theme is expanded upon in a later chapter that talks about the role tests play in giving design feedback and providing the safety net needed to be constantly refactoring.

The book also contains a discussion on of the issues that surround refactoring; why it should be done, when it should be done, and how to explain it to non-technical people so that they will understand the benefits.

The majority of the book is taken up with technical explanations. There is a large chapter describing various ‘code smells’ and the refactorings you would use to combat them (in the kindle edition I own, it even links to the relevant page), this is followed by a comprehensive list of known good refactorings, and the individual steps required to perform them in the safest way possible (particularly useful if you’re unfortunate enough to be working in a language that lacks proper refactoring tools).

The steps are designed such that the compiler (assuming there is one, and that you’re operating in a staticly typed language) will catch most of the issues, and the tests will catch any others.

With each refactoring is both a UML diagram and a code sample showing the before and after, and in the code section the changed sections are highlighted. The examples are kept small and simple, and the format is such that it makes for an excellent reference book. It is trivial to find the section describing the code smell you want to fix, then jump to the set of refactorings required to fix it.

The example refactorings are also split up into larger sections, giving you a good starting point if you notice that the code you’re working on is suffering from a general class of problem, for example there are chapters on Organizing Data and Dealing with Generalization amongst others.

Finally there is a chapter on larger refactorings, this is much more vague, you’ll know it when you see it kind of thing where you’re steadily improving a large code-base over the course of months or years, whilst less detailed, this section is one I know I’ll be returning to anytime I’m presented with a large legacy code-base.