Rating: 
Summary: F A N T A S T I C
Review: This book is fantastic for many reasons - foremost in my list because it indirectly teaches what good OOP looks and feels like in implementation. Many books try to do this, but don't quite do it the way this one does it for me. This book shows you how to detect "smells" in code that need attention. More interesting is how a so-so/poor program can be turned into an elegant piece of engineering that is simpler to read and understand.In addition: * It's well written. * Indirectly shows you how to make better OO code * Section on identifying "bad smells" in code is dead on. * JUnit - a testing framework introduced in the book is fantastic. Must get. - Best programming related book I have read this year (2000).
Rating: 
Summary: Caveat emptor
Review: Be warned: the examples in this book are all written in Java! As a C++ programmer I was very disappointed when I saw that (when I got the book!) IMHO, you should NOT write large applications in Java and therefore you would not need to refactor your code very often. C++ on the other hand is NOT suited for small programs (too cumbersome to just get off the ground, but THEN...) and you'd probably NEED to refactor your programs on a regular basis. The ideas in the book are good and valid, the chosen language is WRONG (IMHO)
Rating:
Summary: A book to read & reread...
Review: Refactoring is a book which details simple techniques of fixing your code to facilitate making changes. The book's main feature is a large catalog of at least 50 refactoring patterns (presented in a similar way to Design Patterns) with a name, example, and motivation for using it. The patterns are described using UML. There are several other chapters of interest, including one on "Bad Smells" which lists many telltale signs of poor programming and how to fix them. Maybe I'm just showing my lack of sophistication, but Design Patterns went over my head. I only "got" a few of the patterns. But this book is much more accessible to an intermediate programmer who wants to improve his coding style. If you've ever wondered how to write more maintainable code this is your book. One good thing about this book is it's directly applicable to almost every standard procedural or OO language, whereas Design Patterns are pretty much for OO programming only. Even if you are writing VBScript or Javascript for your web page you could use many of the techniques illustrated here. Highly recommended. Buy this one.
Rating:
Summary: A Unique Computing Book
Review: Maintaining and modifying existing code is more important than most people realise. Commercially, it consumes more money than developing new code. Unfortunately, it seen as a drudge task and you'll be hard pushed to find much written about it. This book is an extraordinary exception. It covers everything you to need to know about refactoring (improving hidden code whilst maintaining its visible interface). There is advice on when it should be done any many, many examples (templates) demonstrating pretty much every element of refactoring you're likely to need to perform. Of particular note is the emphasis on testing, testing, testing. Athough it is not a book about testing several pages are dedicated to the subject. An introduction is made to his own mechanism for testing (JUnit) which enables code to be tested several dozen times per day without adding any overhead to the delivered code. One of the final chapters is about 'Big Refactoring' where whole classes and not just individual methods are involved. It's a good introduction to the added risks and caution required but would benefit by some expansion. Overall, the book is very well written. I read it from cover to cover and there are few computing books I'd try that with. Finally, a word for the publishers. I have the hardback version an, as with all my Addison-Wesley books to date, it is well put together and should last a lifetime's regular use without falling apart.
Rating: 
Summary: Great book; performance matters; stack uses vector backwards
Review: I liked this book a lot. But the constant de-emphasis on performance worries me. Performance really does matter. The code for "Replace Inheritance with Delegation" shows how to implement a stack by delegating to a vector. In what might be seen as a kind of "Freudian slip" the sample code (p. 354) uses the absolutely worst possible technique! Push inserts at the 0th element and pop removes the 0th element. This is a terrible blunder. It is just as clean and *much* faster to insert and delete the last element of a vector. Steven Tolkin steve.tolkin@fmr.com 617-563-0516 Fidelity Investments 82 Devonshire St. R24D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates.
Rating:
Summary: A MUST READ for anybody who writes code
Review: My prime candidate for the best book of the year in computing. This book makes you feel ists fun to clean up your code. It gives advice on worthwile places and failsave techniques. Its even fun to read. Its biggest disadvantage: its too short. Further reading is Kent Becks great book on Extreme Programming. And thank you Martin Fowler for giving us another book.
Rating:
Summary: Vital for every programmer, of great practical value.
Review: Unlike the AntiPatterns book, this one is valuable to every programmer, not just team leaders and academics. Refactoring is for everyone; I was doing it long before I knew what it was. Simply put, it is cleaning up the design before you add a new feature, so that the new feature will work with the design rather than fight it. The methods outlined in this book go beyond common sense, giving step-by-step guides to help refactoring be done safely and formally. The text is also of great value to programemrs who learned the procedural style and still fealing it lingering in their object oriented designs. I have only owned it for two days and it has already contributed significantly to my knowledge of good object oriented design and implementation. It is one of the few books per year that I can afford to purchase and keep as a reference.
Rating:
Summary: Should be part of every developer's toolkit
Review: I spent seven years in the Smalltalk environment figuring (parts) of this stuff out for myself. You don't have to - buy Martin's book and shave at least a few years off the learning curve. Refactoring is an indispensable part of software development. Like it or not, whatever you write today will be "wrong" sometime in the future. You need to have techniques for transitioning to the "right" stuff. Refactoring provides you with a wealth of small tools that can make the transition easier. Not only that, having confidence that you can refactor your code later (supported by relentless testing) actually relieves some of the pressure you feel when you write the code the first time. Get it working, then get it right. Don't panic. Don't sweat. Enjoy your work like you did when you started (remember?). Let Refactoring guide the way. A practical guide for any OO developer, no matter what language you are working in, though you need enough familiarity with Java to read the examples.
Rating:
Summary: Making tired old code better
Review: The basic thesis of this book is that, for various reasons, real programs are poorly designed. They get that way for a variety of reasons. Initially well designed, extending the program may lead to software decay. Huge methods may result from unanticipated complexity. Refactoring, according to Fowler, is a function preserving transformation of a program. The transformations are reversible, so the intention is to improve the program in some way. Fowler suggests refactoring a program to simplify the addition of new functionality. The program should also be refactored to make it easier for human readers to understand at the same time. He also insists that each step is small and preserves functionality, and on frequent unit testing with a comprehensive test suite. Half of the book consists of a catalogue of refactorings. He gives each refactoring a memorable name, such as "Replace Type Code with Subclasses". He illustrates the design transformation with a pair of UML class diagrams, and has a standard set of sections: Motivation, Mechanics and Example. The Motivation is a prose section that describes and justifies the refactoring, showing the relationship to other refactorings. The Mechanics is a sequence of steps needed to carry out the refactoring, shown as a list of bullet points He expands on some points. The Example is where the value of this book lies. Fowler takes a fragment of Java code, and takes us step by step through the refactoring. The code is small enough that he can show it all each step of the way without overwhelming us, but is large enough to be realistic. The code is clear enough for non-Java programmers to follow. He explains his code well enough for the book to function as a Java tutorial where the meaning of the code is not obvious. One or two of the refactorings are specific to the Java object model, and do not apply to other languages. Other languages would benefit from similar treatment, but there are very few language-specific refactorings. The book is very much of the Design Patterns movement, with frequent references to patterns. The aim of a factoring may be to achieve a particular pattern, or it may take advantage of a particular pattern. The book can be used as a tutorial on Design Patterns. I have a small number of complaints. Fowler advocates the use of refactoring while studying code for a code review. One needs to be very sensitive to the feelings of the programmer here, especially if he or she is a novice. The reviewer should read the code with refactoring in mind, and possible refactorings recommended, but it is for the programmer to make the changes. Reading this book has inspired me to refactor some of my own code. My mistakes underlined the need to take small steps, and to test frequently. I spent a day building a useful Delphi testing framework from the description Fowler gives of the JUnit testing framework. The one category of code that does not seem to lend itself to this approach is some highly coupled parsing code. While I can extract small blocks of code, they remain tightly coupled with each other, and it is hard to give them meaningful names. The answer here may be to use the top down approach of recursive descent, rather than the bottom up approach of refactoring. Perhaps recursive descent can guide refactoring. Refactoring is largely a local approach. One can almost say a pinhole approach. Sometimes a global view is needed. In summary, I would say that this very good book would be of use to Java programmers who have some understanding and much bafflement. It is very good for us older dogs who have become a little jaded and need some new ideas and motivation.
Rating:
Summary: Recipes for improving code
Review: Like the Gang of Four's landmark book _Design Patterns_, Fowler and his cohorts have created another catalog-style book, this time on refactoring. Refactoring refers to taking existing, working software, and changing it about to improve its design, so that future modifications and enhancements are easier to add. _Refactoring_ is primarily a catalog of 70 or so different kinds of improvements you can make to object-oriented software. Each entry in the catalog describes an implementation problem, the solution, motivation for applying the solution, the mechanics of the refactoring, and examples. The book's examples are all in Java, but C++ programmers should be able to approach the refactorings with ease. Often, Fowler diagrams the refactorings in UML, so a little Unified Modeling Language experience will help, too. While the catalog is nice, the kinds of refactorings are obvious is most cases. Even moderately experienced programmers won't need the step-by-step mechanics described. The real benefit, though, is that the mechanics of each refactoring help guarantee that you can pull off the refactoring without introducing new bugs or side effects. They encourage you to take smaller, verifiable steps, than the more gross refactorings that most developers would naturally take. You actually save time doing so. How do you know your refactorings are safe? Unit testing is the answer that Fowler et al. provide. Java developers will find the introduction to the Junit Testing Framework the most valuable part of the book, more so than the catalog of refactorings itself. There's more to the book than the catalog and Junit, of course. There's discussion of the history of refactoring, how to evaluate refactoring tools, and how to convince management that what appears to be an overhead activity is actually useful in the long run. Unfortunately, these sections are all too brief. And there is no discussion of how refactoring fits in with various software development processes. For example, programmers using Extreme Programming (XP) would probably feel right at home with Fowler's recommendations of refactoring in duets and unit testing, but developers stuck with a Software Engineering Institute process like PSP categorize testing as failure time and something to be minimized if not avoided. Cleanroom developers are taught that unit testing inteferes with metrics for quality, and that verifications are what should be done. Should such developers redo verifications after each refactoring? There's no answer in this book. An unusual chapter, called "Bad Smells in Code," gives overall motivation for the refactorings. These vague notions, such as "long methods" or "lazy classes" humorously provide a foundation for starting your own refactorings. I say "humorously" because (mostly) Beck's and Fowler's odd analogies (classes becoming too intimate and delving in each others' private parts) provoke a chuckle (as if a chapter about "bad smells" in code weren't enough). Overall, I've enjoyed reading this book and referring to the catalog while putting my own unit tests and refactorings into practice. Fowler's writing style is smooth and fluid, and it's easy to digest the catalog in no time. The book's typesetting is crisp, the figures quite clean, and both the refactoring index and "smell" index are enormously useful.
| 
