Rating: 
Summary: Improves the way you code !
Review: This is one of the best Java programming book I've ever read, and I plan to reread it ! This book definitevely improves the way you code by providing example of do's and don'ts, together with their justifications. Refactoring, used in conjunction with JUnit (a Java testing framelet), is what could best happen to us OO developers after Design Patterns ! I would recommend the book to any experienced or beginner OO programmer. And, good news, it's fun to read !
Rating:
Summary: An essential book for any object oriented programmer
Review: If you do not own this book you should. The information in this book will make you twice the programmer you are now if you work in any object oriented language. Fowler presents clear and simple ways to take existing code and make them more succinct, modifiable, and comprehensible. He presents extensive code examples that are long enough for you to understand what's happening but not so long that you lose your place in them.The book uses Java as it's language of choice but in most cases this is not a problem. I can only recall a couple of the many refactorings presented in this book where specific focus on Java's way of doing things might obscure the message. If you know C++ or Java you will have no difficulty understanding this book. For the last few months I've been using refactoring in my programming, but until I got this book I didn't have a clear set of steps for many of the refactorings I was doing. Having a refactoring library I can refer back to while programming is the real value of this book. I expect to keep it nearby whenever I program.
Rating:
Summary: Excellent introduction and reference text
Review: What is refactoring, why is it a good idea, and what are good mechanisms for doing so? I highly recommend this text for those involved in software development, especially later in the software life cycle when maintenance is a crucial issue. Honestly, even if you just read the first three chapters you get the gist of the book (the majority of the book is specific types of refactoring) and enough knowledge to decide on whether refactoring is a useful thing for your code base (it almost always is). An excellent look at a crucial part of "Extreme Programming" and a useful part of development of all sorts.
Rating:
Summary: This book fills a glaring hole in the programming canon.
Review: There are dozens of books that will tell you how to write 'reuseable code'. This is possibly the only book around that will tell you how to reuse code and how to modify it to your needs without breaking it. Much of it is common sense (after you've had it pointed out to you) but there's still a wealth of ideas in it that are worth having around, if only so that you don't have to reinvent the wheel' again. Personally, the most valuble knowledge I gained from the book was the relatively minor bit on unit testing. The concept of writing and starting code tests before writing the code has rippled slowly through the way I work and enriched it enormously. For me the book has been worth it on that front alone. V.
Rating: 
Summary: Make sure it is relevant before you purchase.
Review: I am a perl programmer. I also write C and I do a lot of UNIX shell programming as well. The ideas contained in this book are helpful, but largely irrelevant and poorly applied to code you may be writing -- unless you are writing in Java. As an academic text, it is nice to have on the shelf for when I want to go and really tear into something on a theoretical and scholarly level. But for day-to-day programming, there are much better texts.
Rating:
Summary: Focused methodology; improve your code and productivity
Review: The concepts presented in this book are not revolutionary; they will not fill you with a sense of monomaniacal purpose. Rather this book focuses on the real issues of developing software, and describes a very simple tool for getting work done effectively. After fifteen years of developing code, I already did some of the things this book articulates; but now I do them consistently and without compromise, and my productivity has gone up while my defect rate has gone down. Subtle and quiet, perhaps, but that's powerful stuff.
Rating:
Summary: An Essential Reference
Review: There are three books every Java programmer should have on his or her desk -- "The Elements of Java Style," "Design Patterns," and this book. Of the three, this is my favorite. "Elements" is excellent so far as it goes. It provides eminently sensible coding standards. There is a deeper sense of style that is addressed by the second pair of books. This has to do with the conceptual organization (or re-organization) of code. My only complaint against "Patterns" is that many of the examples are in Smalltalk, a language of more interest to academics than programmers. All of the examples in "Refactoring" are in Java. The book falls into three parts -- introductory material, a catalog of refactorings, and guest chapters by refactoring reseachers. The first part sets the stage for the catalog. So, what is refactoring? It is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior." How do you know when to refactor? When the code smells bad. There is list of bad smells. These include duplicated code and long method. The catalog itself constitues the bulk of the book. Each refactoring is named, described with a short summary, motivated (why should/shouldn't it be done), described with step-by-step mechanics for carrying it out, and illustrated with a simple example. An example is "Extract Method." This is appropriate where a segment of code requires a comment to understand what it's doing. Extract the segment as a method and give it an appropriate name. An appropriate name makes the comment superfluous. A fundamental underpinning of this process is having good tests. Changes are made incrementally with tests at each significant step along the way. Tests must be automatic. As the author notes, JUnit (at www.junit.org) provides a suitable testing framework. The last part of the book is largely guest material. Some is helpful, like Kent Beck's chapter "Putting It All Together" and some not so. That there is refactoring tool for Smalltalk is not terribly interesting if the chances of your programming in Smalltalk are nil. On the whole, this is an excellent book. Knowing the techniques involved in refactoring can vastly improve the quality of existing code. Indeed, good programmers instinctively employ some refactorings as they code. Access to a fuller catalog than those instinctive refactorings is a boon.
Rating:
Summary: Integral for development
Review: I was fortunate enough to work with Martin on a project at Netscape a few years ago. I have been able to leverage what I learned there in many ways since. In a modern iterative and incremental process, refactoring can be a phase of each iteration. So say you do some analysis, design, code, testing in your first iteration. There can also be a refactoring stage added to "clean up the code" and shift the design. Usually people are doing this anyway in the design and coding stages. However, decoupling refactoring in the spiral process can separate concerns so that the next iteration can cleanly focus upon drilling down further or adding functionality as it should. So obviously the notion of refactoring is critical to development. This book serves as a beginning for a similar literature that exists for design in the form of patterns.
Rating: 
Summary: What I learned from this book is...
Review: I haven't read it completely but what I learned so far is that it is not wrong to change things after a while and that change is even needed when more and more requirements drop in... A lot of the refactorings are obvious but -the same like Design Patterns- it gives a name to these refactorings which is usefull in team development.
Rating:
Summary: 50 page book expanded to over 400 pages
Review: The subject matter is very pertinent, but the book could have been more to the point. Some of the pages have only four lines of code; I could not understand why so much of space was left blank. Many of the techniques taught are not new and should be part of development and refactoring. It would have been nice if the authors went through each other's manuscripts and REFACTORED the book, because the book is full of repetitive material.
| 
