It is now 9 years since I wrote this review. In retrospective, the most important
thing I got from this book was the message:
"Don't ask your manager if it is okay to refactor. You are hired as a professional
to do the job the way you judge is best". I've since then upped myself and gotten
the courage to just change what I've found to be inappropriate design. Of course,
always consulting the rest of the team first (unless very small refactorings, local
to "my own" code).
I guess today (in 2009) you can find much better books on unit testing, and perhaps
also on refactoring. The catalogue of refactorings may seem a bit unnecessary and
no-brainer-ish, to an experienced developer.
When I wrote this review originally, I had
2 years of experience. Now I have about 10. I look at books with different eyes now.
Refactoring as a concept is definately important, but I am not sure anymore that this
book is the best option you have to learn this.
Anyways, this book started a trend. This trend has resulted in much more litterature and
experience in the subject. Some of this later litterature may of course out-shine the earlier
litterature, like this one. We, as individuals, as community and industry, are learning all the time.