Rating: 
Summary: A quality book that teaches quality code!
Review: This book teaches how to clean up dirty code and build a better design out of existing code (which, unfortunately, is usually badly structured...)The GoF Design Pattern book discusses ways to design quality code from the very start; The Fowler's Refactoring book discusses ways to make quality code out of all the existing hard codes! Both of them are indispensable for programmers with a penchant for quality code!
Rating:
Summary: Absolute required reading for OOP developers
Review: After a year of OOP with C#, I finally feel that I'm writing some well written code with the help of Martin Fowler's Refactoring. Fowler defines a number of "smells" indicating areas of your code that may need refactoring. He then offers clear and concise methods for clearing the smells; resulting in more extensible and understandable code. This book is great for learning refactoring and as a quick reference...it should be found on every OOP developer's bookshelf.
Rating:
Summary: A must have...
Review: This is an excellent guide to some activity that almost 99% of we, the real programmers, do all the time: refactoring. Is true that some of the refactorings are common to us, but the merit of Fowler is the effort to catalogs them for an easy reference and communication. The book is an excellent reference for this simple quality. I didn't remember any of the refactorings that hasn't any pertinence to the most common OO programming language (C++, Java, C#, VB.NET). This book study the process of writing code as a technique that can be studied, comunicated and learned, more than simply learn the syntax of the language. Also there are not so many references outer for coding style and techniques that this book seems an "oasis in the desert".
Rating:
Summary: Better than you can imagine
Review: Do not be fooled by the title: This book works just as well as a style guide for class design in new development as it does for rewriting existing code. The writing is easy to understand, and the examples are kept simple for clarity. It works well both as a reference and as a cover-to-cover read. The book also helped illuminate many design patterns. The only downside: After reading this book it was almost painful to go back and "smell" my own code. But I immediately set about refactoring, with tremendous results. This book is a "must-have."
Rating:
Summary: Just get it!
Review: I think that this book should be on evey programmer's shelf. Having all of the refactoring patterns in one place makes the book more than worth the price.
Rating:
Summary: The Book must be on Book Shelf
Review: The first chapter guides programmer to the gate of refactory. It talks about why you need it, how you do it. At the second half of the book, it provides a reference of refactory methods. Its role is like a Dictionary. And the refactory methods fit in many daily cases.
Rating:
Summary: Don't wait as long as I did
Review: I've known about this book for over a year. Initially, I thought it was about re-engineering legacy systems. I don't do that, so I didn't give it much thought. Over the past year, I have stumbled across repeated references to this book. Everyone seems to cite it, and now I understand why. It's very easy to fall into 'analysis paralysis' when doing object design. A commonly heard complaint is "I have created 27 different class diagrams, and 42 separate sequence diagrams, but I can't seem to get any code written..." XP's popularity is due, in part, becuase it get's you into action--you begin writing code immediately, instead of creating diagrams for weeks (or months) on end. XP's motto could be "just do it!" But how does one reconcile this "code first, ask questions later" mentality with an acknowledged need to at least do some design work? In "Refactoring", Martin Fowler provides the answer. His prescription is to create some code to get something working, then look at the code to see how it might be improved-- refactor it. In Fowler's view, you won't really understand the problem until you have coded it, so instead of spending the next three weeks trying to find the perfect pattern for your next task, forget the pattern, and get some code going. Once you've got something workable, then think about patterns you might back into from your existing code. Of course, that's a gross oversimplification of the process, but it gives a flavor of the ready-fire-aim process that 'Refactoring' is built around. And it seems to work--even people who don't buy into other core practices of XP seem to have adopted refactoring as a central element in their process. The catalog of refactorings that the books provides are a first class reference on how to clean up particular problems. But to me, the most valuable part of the book is its first fifty pages. Fowler starts the book with a simple, but ugly, example, that he proceeds to refactor, step-by-step, into something rather elegant. If you like to learn principles first, you might want to read the second chapter before going through the example, but I found it a very valuable exercise. I recommend coding the example in your language of choice, then refactoring along with Fowler as you work through the example. There is a temptation to relegate refactoring, like testing, to simply another development technique. But like testing, refactoring is at the core of a development philosophy: "I know I'm not going to get it right on my first pass, so I'll be satisfied with making it as right as I can. Having done that, I'll have a much better idea how to make it better, and I will. But time's a' wasting, so I need to get moving." This philosophy of continuous improvement allows the developer to get into action fairly quickly, and it reduces the risk of failure-by-delay. Fowler's book is a top-notch resource that will help the developer create more flexible code more quickly. I can recommend 'Refactoring' without reservation.
Rating: 
Summary: Shallow, verbose, and too ambitious
Review: The book attempts to match the Gang of Four book in both format and effect. Unfortunately, it fails. The author spends so many pages explaining trivial refactorings such as renaming a method or introducing a constant. Any software developer with moderate experience would now how and why to perform such tasks without any need for such a book. The book doesn't cover more complex or exotic refactorings that are of greater value to the experienced developer, and it doesn't touch upon the impact that refactoring might introduce into existing code and how to manage and minimize that impact. However, it does contain some useful tips on correcting some classic design mistakes using refactoring, which might prove valuable to the novice. Thus, the two-star rating.
Rating:
Summary: An Inhibited Programmer is often a Less Productive One
Review: This book is a classic, it changes the way you think about programming. If you are two or three years into your programming career, you have probably had the urge to take a project and redesign it from scratch. You may have said to yourself "if only I had known about x methodology or y framework, this code could have been a lot cleaner." Sometimes these experiences can amplify a programmer's inhibitions. An inhibited programmer is often a less productive one. Refactoring eases a programmer's inhibitions in two ways. First, it shows why there is no need to create a PERFECT design up front. If better ideas emerge later, they can be integrated safely and securely. Second, the book provides methods for changing existing code using step-by-step "recipes" for dozens of refactoring scenarios. These recipes guide you through the tasks in such a manner that all possible holes exposed along the way are protected. Another small gem of this book is a guide for identifying "code smells". Code smells are pieces of code that compile, test and run correctly but nonetheless look bad or ugly. The section on code smells help you pinpoint what is ugly about it. As they say, "a well-stated problem is a half solved one". After reading this book you will finally understand the XP edict "Refactor early and often".
Rating: 
Summary: Refactoring: Why and How
Review: Before I read this book, when someone mentioned refactoring, I would imagine it would be either "code cleanup", e.g., refactoring out the common behavior to the base class or a subroutine or "total redesign", e.g., breaking up current architecture, all these two can be avoided and unnecessary if we analyze the problem right, abstract the model right, architect the application right, design and code right. I am a bigot of OO technology, design patterns, iterative software develop process from analysis, architure, design, construction to testing, and I know to get all the above things "right" would be very hard if not impossible at all. But that is what our designers and developers' job, facing the challenge right? So how is refactoring going to affect us as designers and develoers? The first chaper(example) is particular interesting and attractive to me, as it just pointed out some signs of "evilness" in the design, e.g., a lot of tag/case for runtime type checking, responsibility was assigned to the wrong class, inaccurate/insufficient abstraction. Actually, it is this chapter which made me decide to get the book and see how the author would correct these problems. Mr. Fowler did excellent job on this topic. Most Software developers may not have the luxuery to always work on the new project from start, we may inherit legacy codes which was not designed to solve today's problem, even an initial good design could go decayed, be it lack of documentation, insufficient of communication, different levels within the develop team, etc. Now with this book, we can take a breath and start refactoring the existing design/code to make it solve today's requirement, to even make it extensible for tommorrow's change. Initial design is no longer a huge burden, as it can be refactored, extended to fit the unseenable things when it was made. The only thing in this book that annoys me is the verbosity of the refactoring steps in each chapter. It exposed to much details. I think the text decription and UML notation would be enough for any experienced developers to see the design problems and how to correct them. All those steps would only serve the needs for refactoring tools developers. But even with all the details, it is a "light" reading :-)
| 
