Rating: 
Summary: At least as important as Design Patterns. Buy it now.
Review: It's a rare book that causes the reader to say: "This changes *everything*." The Design Patterns book is one such, Refactoring is another. The introductory chapters establish a clear theoretical and practical basis for the catalog of refactorings that make up the larger part of the text. Many of the examples are trivial, but then, many of the refactorings occur in simple situations. The more complex refactorings are usually accompanied by detailed example code. The mechanics section in each refactoring is an outstanding tool, and I expect to use it quite frequently. I have followed the 'extreme programming' (XP) movement for some time, and I'm an ardent fan, as is, so I gather, Fowler himself. But don't be fooled by this: the book is not just for the XP crowd. All programmers who use Java (or have used more than one other oo language), will find this book a huge resource. I have a library that I recommend to journey-folk who aspire to mastery. Refactoring is certainly the newest addition. I think this book will be an instant classic. I cannot say enough. Why not buy it now?
Rating:
Summary: Must be on your bookshelf
Review: If you are a professional developer, this book is a must have. Change is the norm in today's development organization, and the ideas and refactorings in this book will help you make changeable, maintainable software.
Rating:
Summary: This book is changing the way I program.
Review: This is a terrific book that shows you how---with discipline and care, but without magic---you can improve the internals of existing programs. We've all come to believe over the years that software inevitably becomes more complex and brittle as it evolves and is maintained, but refactoring shows that it doesn't have to be that way. We're very lucky that the first book to cover refactoring in detail is such a gem. The organization of this book is similar to that of "Design Patterns": introductory material that explains what refactoring is, how it works, and why it's important, followed by a catalog of refactorings that you can use in your programs. Fortunately, Fowler is a very entertaining writer, and "Refactoring" is much easier to read than "Design Patterns". Furthermore, many people, especially beginners, find it easier to see how to apply refactorings than patterns, and the book contains first-rate tips for identifying code that needs to be refactored. If you write code, buy this book. Read it. Apply it. Your employers and your fellow programmers will thank you, and you will enjoy programming more.
Rating:
Summary: An essential book for OO developers
Review: Refactoring is another must have book for any OO developer. As with other books like the Gang of Four "Design Patterns", Mr. Fowler has compiled, structured, and systematize a set of common practices that any OO developer does in his/her day-to-day work. Refactoring consist roughly in reshaping and evolving your code without changing its interfaces in order to improve its internal structure and functionality as well as other attributes. Every developer knows that is very difficult to hit the bull's eye at the first attempt and the code once written must be changed a number of times to accomodate new functionality or requirements or to allow the reuse. Mr. Fowler starts explaining what refactoring is using a pretty well documented and complete example, next he describes when, why, how, and where you must refactor your code and how to locate those pieces of your code that are suitable for refactoring and how to test those changes. Finally, the bulk of the book is devoted to a catalog that identifies and classifies the different refactorings. The book id full of code examples in Java, easy to read and right into target. From my point of view is a good investment for any developer.
Rating:
Summary: Very valuable contribution towards Programming folklore.
Review: First one small complaint about this book: It introduces the notion of "bad smells in code" which are nothing but "Anti-patterns". Why introduce another new term? The notion of "Antipatterns" was introduced by another book with that title. That book too handled some of the issues of "Refactoring" although at different level and hence should have atleast been mentioned in the bibilography. Interesting thing is that the "Catalog of Refactoring" in this book is in inverse format of the "Catalog of Anti-Patterns". That is not a bad thing though. Many thanks to all these authors (like the GoF and Fowler-Beck-gang) who giving the OO programming world a higher level vocabulary, by giving names and cataloging simple types of changes that you make to your code to rejuvenate it. That is a very important contribution towards documenting valuable programming folklore. The book is pretty focused. The authors talk of little Refactoring. And don't digress into suggesting ways to handle Architectural or Infrastructural Refactorings (like say moving from Monoliths to N-Tiers). That makes it a fun yet valuable read. -------------------------------------- This are my own views not my employers
Rating: 
Summary: Competent And Influential
Review: Fowler's refactoring has become a classic in the field of popular software engineering books. It's a good book that clearly explains the basic ideas of refactoring and develops a standard vocabulary for refactoring; the power of this vocabulary is demonstrated by the development tools like IntelliJ Idea and Eclipse that now incorporate its nomenclature directly to allow rapid automated refactoring. Refactoring together with Test-Driven development, both concepts developed largely by Kent Beck as part of his Extreme Programming methodology, are in my opinion the most powerful and innovative ideas in the last 10 years or so in software development. It is a fairly quick read for an experienced developer, and often admittedly presents concepts that any experienced develop would have discovered on his/her own. Nevertheless, all of the refacorings together in one book serve as an excellent reference and reminder. I think this book certainly belongs on the bookshelf of any developer wishing to improve his or her craft.
Rating:
Summary: Teaches concept not coding
Review: Some of the reviews here have focused on this book as a way of learning coding techniques for refactoring. Other reviews have focused on refactoring being another term for what they have already being doing. While learning some new coding techniques might be a side effect of reading this book, the real value of this book is descibing a process and terminology for facilitating refactoring - something that many developers have done on an ad-hoc basis for years. It has been invaluable in broadening the acceptability of refactoring, an activity that was often dismissed as not being a good use of development resources time. It also gives a vocabulary for discussing refactoring rather than relying on engineers own adhoc practices. And there's probably a few refactoring techniques that won't seem obvious.
For C# users, you may wish to look at NUnit.org for a .Net version of the JUnit software mentioned in the book.
Rating:
Summary: Finally, the technique has a name!
Review: Although this book has been around for a few years now, the technique that Fowler names "Refactoring" is as old as programming. I've been doing refactoring for the twelve years I've been a professional programmer, often to the chagrin of my supervisors; they often seemed to subscribe to the "if it ain't broke, don't fix it" mentality. Yet I could always tell that the code *was* broken, even if it didn't appear that way when the product was used. I was beginning to suspect that I was the only one who saw this, and then I read this book - written by an eminent researcher in the field and one of the brightest people to ever put pen to paper.
By giving a name to the technique, it can be talked about in planning/design meetings, discussed as a best practice, measured, and demonstrated. But Fowler takes it much further - he gives names to common refactoring techniques as well as what he calls "bad smells", or signs that you need to refactor. ("Speculative generality", for example - a perfect name for an annoying tendency of the 10,000-foot architects).
This book is well-researched and well thought out, and is a must-read for anybody who's serious about software development. It's principal value is in providing common terminology for common actions, in addition to good justifications for each refactoring.
Rating: 
Summary: Disappointment
Review: It doesn't happen often that I finish a book within 2 days. This time it is because there is surprisingly little new stuff for experienced programmers. It is well written and probably of use for beginning programmers, but as I went through the refactoring patterns, I kept saying to myself: "yes of course, I do that all the time.., where are the flashes of new insight?".
Rating: 
Summary: Not so good? It's posible?
Review: I'm surprised with the high Refactoring's Rating. I've read GoF Design Patterns and Fowler Refactoring is not able to reach the experience. Is simplistic, don't give you nothing new on OO programming, and don't have the category to became a classic.
Perphaps I'm not a great programmer (who knows...) but the Refactoring's seems a child story. I'm sorry, many people talked amazing things of Fowler UML distilled. Perhaps, but this is not the case.
For middle brained, s quarter of programmer, I don't recommend the book. Only if you're interested in something like "which're the refactorings (intuitive) algorithms to implement in some place" try it.
| 
