Rating: 
Summary: Become a better programmer.
Review: After reading this book I'm a changed programmer. I have always thought good code was important, but never had a very good way of insuring that my code was well written and tested. Refactoring has greatly changed my thinking on how to go about writing code and I've found that my style is much better.Thanks "Gang of Five"! *grins*
Rating: 
Summary: red light, green light
Review: The most useful hint for me is the author's advocacy of the JUnit class for unit testing. (I haven't noticed any previous author's review elaborating on his or her experience with JUnit, so I will give some detail here.) I did download JUnit, and wrestled for a couple of hours to get the thing to do what the docs said it would do. Once successful, I set about modifying some of my Java code which had over time become brittle. Over the next weeks on a part time basis (that is, having the code design swapped into and out of my brain at irregular intervals) I was able to rewrite several important classes with a security that I had never before enjoyed. The author claims that incremental testing enables a freedom in the code modification process; I found that claim to be true. The interactive JUnit class displays a red bar if an error has been introduced during code modification, and it displays a green bar if all tests still perform as expected. I found that the red light, green light provided an unexpected, visceral motivation to test. As far as the refactorings themselves - well, I read some and agreed with them, but in practice on the keyboard I just zipped along with my own instinct. I didn't really want to take the time to know whether my proposed refactoring had already been cataloged. I am confident that the book, which is thorough, contains some golden nugget hints that I haven't yet encountered in my own programming experience. But I have not been attentive enough to read the book like I would a textbook.
Rating:
Summary: Excellent catalog of source code transformations
Review: Learn how to improve your code using 73 refactorings. Sixty seven percent (49/73) of the refactorings are specific to object-oriented languages such as Java, C++, and Smalltalk. Refactoring promotes a healthy approach to maintenance programming. "When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature." Fowler's systematic approach and insistence on regression tests insures that each refactoring will not break any existing code. The constant application of appropriate refactoring results in reliable and clear source code. Some refactorings are opposite pairs such as "Add parameter", "Remove parameter" and "Replace Delegation with Inheritance", "Replace Inheritance with Delegation". A refactoring may have significant downsides, for example "Preserve Whole Object" increases coupling and "Replace Temp with Query" decreases performance.
Rating: 
Summary: Good Information But Extremely Poor Delivery
Review: This book contains some good information on how to improve yourexisting code without rewriting it entirely which is a nice departurefrom the norm of most of these UML-type books which advocate totally changing the way you design and build software. Not that the Unified method of designing and building is bad, its just that its hard to change the way this is done in an organization when you're not in charge of the organization. Mr. Fowler has put forth a mechanism for improving the design of existing code while adding functionality to it. And the information, once culled from the surrounding text, is extremely useful. It's not paradigm shift. And it's not a companion to Design Patterns - Fowler mentions the Design Patterns book throughout his text but this book is certainly not written for the same audience. Fowler never once gives an example where he converts bad code into good by utilizing a pattern from the Gang of Four's book. The book is useful for ANY object-oriented language even though he uses Java in his examples the principles map easily to C++ and SmallTalk. Almost all of the techniques are common sense and yet he spends the bulk of this book explaining in simple terms how to perform them. For each "refactoring" he capably provided a two or three sentence overview of the process, and a code fragment or class diagram exemplifying the technique. These summaries and figures are excellent. But his tone becomes condescending as he painfully explains the process of performing the code improvement. For instance, Extract Method, the first technique in the book, is succinctly described with: "[If] You have a code fragment that can be grouped together...[then] Turn the fragment into a method whose name explains the purpose of the method." Pretty simple and probably not quite enough to totally understand what he is talking about. But then he has a wonderful little code fragment that illustrates it perfectly. This requires about half of one page. But he spends four and a half more explaining how to perform this simple cut-and-paste. 270 Pages of this 418 page book are spent describing 72 techniques in this kind of excruciating detail. Eight very useful pages are spent describing the bad "smells" in your code that lead to these "refactactorings". Another 110 pages is spent telling you how to justify the work to your boss, encouraging you to do it whether or not your boss approves, advocating a "test-small-change-test" paired programming technique characteristic of Extreme Programming. The final 30 pages are written by the other contributors. Altogether, I think this book should be "refactored" into a 100 to 150 page soft-cover manual reminiscent of Scott Meyers' Effective C++ books. If you're looking for Design Patterns: Part 2 this isn't it! END
Rating:
Summary: Great Book
Review: I won't go too much into it because it would overlap the other reviews. This is really a good book, just like "Design Patterns". If you have that one then you need to get this one. If you don't then you need to get both. All examples in this book is in Java but it easily applies to all other languages. You may already be doing some 'refactoring' without knowing it but this book solidifies the concepts.
Rating:
Summary: Not just for Java
Review: This is a book that will change the way you view code - as you are writing it and when you are maintaining it. While the examples are written in Java (and a couple of the refactorings seem to be Java-isms) this is a book that should change the way you look at your code - no matter what language you use. If you look at any code at all - if you are author, maintain or review code in any language - you should get this book, read it, and leave it on your desk. Like many fundamentally good ideas, refactoring seems so simple that one wonders why we didn't think of it before. Fact is, refactoring has been happening for years (decades) but Fowler is one of the first to make this process accessible. If you are a very experienced developer, this book will help you put some of your own practice into words, to explain it to other developers on your team. You will probably learn a few new wrinkles as well. If you are a less experienced developer, this book can help you to become better at your craft. You'll find out some of the "tricks of the trade" used by the best developers (those who produce the most reliable, most maintainable code).
Rating:
Summary: Incremental changes can and do make a difference
Review: The majority of books describing the development process deal with the design phase. Clearly, this is important, but the latest information is that eighty percent of development time is now spent in the area known as software maintenance. Information concerning how to perform this vital function correctly has been conspicuously deficient. After the publication of this book, that oversight is substantially corrected.
Refactoring is defined as the modification of pre-existing code to improve the performance, and does not directly involve the modification of code to add additional functionality. That aside, improving the efficiency of the code is a valuable goal that is now more attainable.
Given a system that does work, making changes to improve performance is often not a high priority. In the high speed world of software development, making a change that adds only percentage points of improvement in one area does not raise eyebrows, it tends to create frowns. However, like so many other things, this is a very short-sighted view. In my mind, the most significant lesson of the Y2K event is that code tends to live a long time, despite dramatic changes in the hardware. Those simple changes that we do now may not save much time per execution, but iterate that over decades and the return on investment is quite high.
The most significant advantage of the improvements described in this book is that almost all of them can be implemented fairly quickly and can be verified locally, without global recompiles and exhaustive retesting. Therefore, the management decisions that need to be made to carry them out entail much less risk. It is also much easier to allocate resources if it is known with a high degree of certainty that the modification will be completed in a matter of hours rather than days or weeks. This is also consistent with the body of evidence that is overwhelming in favor of a software development cycle with small iterations that can be quickly completed.
No one single refactoring operation listed here will change your application from a tortoise to a hare. However, each one will add a bit more bounce to her step, and if you perform enough of them, you will have either a very fast tortoise or a slow hare. This is a book that should be required reading in all sections that perform software maintenance. If I were in a position of maintaining software, I would create a checklist of refactorings and simply step through that list looking for places to make the changes. There is no doubt that this is one of the best books of the year.
Rating:
Summary: Useful book for professional developers
Review: This book make systematic the steps of fixing the design of poor or mediocre code. Experienced programmers might be put off by the apparent simplicity of many of the steps described. But more important that the individual steps, is knowing when and where to apply them, improving the efficiency of the process and the quality of the result. After all life is too short to waste on reworking code for any longer than necessary. You can also apply the methods in this book to your own design before you implement it. This book is a useful companion to "Code Complete", but if I had an empty bookshelf I would buy "Design Patterns" and "Code Complete" first.
Rating:
Summary: Incredibly useful
Review: Having inherited and written code so incomprehensible it might as well be written in ancient Etruscan, I keep this book with me whenever coding. This book is probably one of the most useful books on programming in my possession. It takes an example-based approach to refactoring, and includes a well-written catalog of refactoring methods.
Rating:
Summary: Best Practices for Object-Oriented Development
Review: This book is a must read for every OO programmer. It gives a lot of helpful hints and opens your eyes for traps and pitfalls. Even if you are starting a new development the refactoring catalog will definitely lead you to a better design and a more understandable software. Some of the refactorings are just Java-idioms but most of them are nonetheless useful for C++ development.
| 
