Martin Fowler (1999)
Review date: August, 2008

Why not learn by example? The first fifty pages go through a small, but poorly written piece of code. Stepwise transformations and refactoring patterns from the book are applied on the code, while class diagrams are used to illustrate the changes in design.

Next comes a general discussion chapter that defines refactoring, discusses refactoring scenarios, pros and cons, and gives a historical background. This is the "theory chapter".

"Bad Smells in Code" is dedicated to analyzing phenomena and structures encountered in code, that make the code bad. Implications of these structures are explained. Then comes a lighter version of a JUnit vanilla chapter, but it's rather short and focused on how tests relate to refactoring.

The heart and core of the book is made up of the refactoring catalog, which in turn is organized around topics like:

This makes a rather comprehensive list. For every category mentioned above, there exist several refactorings, and they are all described in terms of motivation, mechanics, and an example.

The book ends with a discussion on big refactorings and some "putting it all together" chapters.


In short, read this! This is a frequently quoted book for very good reasons. Not only is it (to my knowledge) the first of its kind, it also provides a comprehensive and complete catalog of refactorings.

These are the reasons why this book is often quoted, however, I would say that it contains another jewel, not often mentioned: Chapter three, where "bad smells in code" are discussed, gives you the ultimate ammunition for initiating change. Often you end up in a situation where you see a piece of code that simply sucks, and you want to get an approval from your manager or project leader to change it. This may prove to be a difficult task, in which this chapter helps in two ways. First, the author manages to classify and name phenomena in code that you instinctively know are wrong, but may lack an academic description of (at least I did). Second, armed with this new vocabulary you can start making statements like: "This code contains a lot of long methods, shotgun surgery, and data clumps. These are structures identified as bad by Martin Fowler, a well-renowned guru of software development, so therefore I throw them away".

Maybe I wouldn't phrase the argument using these exact words, but the meaning would be the same...

The refactorings then? Some are trivial, almost not worthy of getting a fancy name in a catalog, others are more sophisticated. I also don't agree with all of them, since applying them may indeed reduce code duplication, but make the reading difficult instead, but on the whole the catalog is very good!

As I said before, there's a mechanics section for every refactoring. It decomposes the actual process into tiny atomic steps. When I refactor I don't follow these steps slavishly (shame on me?), so I can't make a statement about whether this way of describing them is good or not, but when reading those sections, it seems sound.

Once again, I regret reading such a fundamental book so late in my career, and I want to recommend it to everybody who has more than one to two years of experience with Java or a similar language.

Who should read this book

To benefit most from this book you should be comfortable with Java (because that's what this book covers), and have some experience with legacy code bases and maintenance programming. C++ programmers may also benefit from the majority of the patterns, or at least get their thinking going.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.