I picked up this book at the wrong time. The book was so successful that a second edition is due out on November 30, 2018 (less than two weeks from now).

On the other hand, I picked up this book at the right time. At work, my project is in the midst of a refactoring project. I am in the middle of changing PHP code from modular functions to object-orientation. The aim of this transition is to enhance the scalability of the project and ease the writing of documentation. I generally like to peer "beneath the surface" of skills that I acquire; this book has indeed enlightened my mind to details of what is going on in my code rewrite.

Some of this book is incredibly tedious. It details how to change code from one format to another. It's work that I let my fingers do more of - and my brain less of! But the book also frames how to do this work and why it is so important. It ties together intellectual "loose ends" which might not be tied together by the programmer who simply dives "head first" into the project.

Fowler writes in tandem with a research seminar at the University of Illinois who have pioneered object-oriented techniques in Smalltalk and then Java and C . They tackle the concepts of refactoring more than how to tackle the specifics of coding in a language. I prefer their theoretical approach to more common approaches drenched in technical lingo and programming tools. This book was worth its time.
( )

We're spoiled now that a modern IDE like Eclipse has so many build in refactoring tools, but this was a pivotal book in programming. ( )

This is the book that moved refactoring from the focus of a narrow community to a general concept. Illuminating, well-written, and helpful, it strikes an effective balance between the concrete and the abstract. Any OO developer should have this on a shelf beside Design Patterns, with which it is nearly contemporary. ( )

Highly Recommended by Dr. Gallegos. Should be on every software engineer's shelf.

Pros: presenting refactoring as a regular part of the development process is an important step forward. The example at the start of the book is a great demonstration if why this stuff matters. Nice to systematically catalog code smells.

Cons: the code smells section is great, but has no actual code examples. The chapters that go through the refactoring moves are better, but having each one isolated makes it boring to read. The big refactoring chapters are only UML diagrams, which are not good teaching aids. I think walking through a few medium sized examples, as in the first chapter, would've been more effective.

Finally, the exclusive focus on java and OO makes sense, but misses much of the power of functional programming, which removes the need for some types of refactoring entirely. Also, it's a somewhat old version of Java, so the content can feel a little dated.

Overall: an important book to get a sense of refactoring, but the examples leave a lot to be desired.

Good quotes:

With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

It reminds me of a statement Kent Beck often makes about himself, "I'm not a great programmer; I'm just a good programmer with great habits."

A heuristic we follow is that whenever we feel the need to comment something, we write a method instead. ( )