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.
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.