Refactoring: Improving the Design of Existing Code

Refactoring definitely embodies the phrase "don't judge a book by its cover". Unfortunately I did this and missed out on a great book for too long. Franky, this thing looks like a text book... not something that would be an easy, enjoyable ready. However, this is exactly what it is.
Fowler's conversational style keeps the book moving and very enjoyable. He opens with a refactoring walkthrough that introduces you to the general concepts. After this the book catalogs all of the refactoring methods and really becomes more of a reference. In about 30 minutes you can read the first few chapters and come away with a good appreciation for the book.
If you've been programming for a while you'll probably find that you were already performing many of the refactorings. This book takes what you've been doing intuitively and formalizes it, much like Design Patterns.
Those that are new to programming might find the book a bit confusing since many of the refactoring methods are opposites of each other. Experience really drives the decision of which refactoring to use. That said, Fowler does a good job of stating the intentions behind each and providing good examples (all in Java, but simple enough to be understandable even if you aren't familiar with the language).

I had done refactoring before I had read this book.But I didn't know until I read the book that the technique I was using is called refactoring.Thus all those people out there who are code reviewers/analysts should read this book to get a sense of uniformity.
Martin Fowler has done a very good job in actually putting down some laws for OO programmers.But all these laws can also be applied to other languages(apart from Java in which most of the examples are written) too.Waste of effort in coding unnecessary lines can be prevented by following some of these laws.Code maintenance can be effectively made easy.Thus redevelopment time can be cut and therefore cost of design changes can be kept low in the long run.Repetition of code can be checked.
The book tries to bring to a form of template some loose comments about doing redesigning and rengineering of code.Another good thing about the book is that it tries to keep the examples simple and easy.Thus fundamentals are conveyed easily.Some of the examples can be confusing but most of them are crystal clear.I would recommend this book to both experienced and novice programmers.It is an essential guide to experienced ones because they can reengineer their attitude towards coding while the beginners can learn good things at the start itself.People who like me(I did refactoring in a project using Borland Pascal 7 for a billing application)have done refactoring before can read the book to discuss and open their mind to new ideas and maybe suggest some new good examples.
I would suggest that refactoring be followed in most B2B,B2E,B2C,J2EE projects mainly.Refactoring under structured methodology may not be very useful to do as it might not be very necessary and may not yield the same return it does in an OO environment.But still,good habits are not bad to follow whatever the environment is.

Not many books on software engineering that were published in 1999 are still worth reading. THIS BOOK IS. I lend this book to my software engineering students more frequently than any other book in my library. Most students who borrow it buy a copy for themselves. Fowler's explanations are clear, his material is well-organized, and his tone fosters enthusiasm. The book has been helpful to undergrads in their second semester of programming and to advanced graduate students. Many students will find it helpful to work with this book in conjunction with Wake's Refactoring Workbook.

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.

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 [...]) 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.

The refactoring concept fits perfectly with extreme programming (XP).
XP (aka ready-fire-aim) recommends that developers get the solution coded and working ASAP (without big-up-front-design or analysis-paralysis) and then (shed your inhibitions; you won't really understand the problem until you've coded it) gradually improve on the design by refactoring the code.
This very accessible book has contributions from Kent Beck, John Brant, William Opdyke, and Don Roberts.
The author uses fragments of Java code to demonstrate refactoring.
The book contains a section on code "smells" that identify ugly code and a catalog of about 50 refactoring patterns, diagrammed using UML and documented per the template popularized by "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma et al.
In his book "Extreme Programming Explained: Embrace Change," Kent Beck has this to say about Martin Fowler's book "The reference for refactoring. Get it. Study it. Use it."

Great advice on when, how, and where to refactor. It also surprised me by having a bit more relevant stuff for big projects than the usual software principles and practices books do -- I'm used to having to extrapolate for myself. In addition to the great text, there's also a wonderful encyclopedic list of transforms. They're understandable enough to read and perform as a human, but also semantically well-defined enough to make tools almost directly on top of.
The last few chapters unfortunately felt 'stapled' onto the end. They all had a very different feel from the rest of the book and, while they were interesting viewpoints, they made it lack some consistency. It would've been good to have either Fowler-ized them or just left 'em out. I'm not clear how much value they added, other than saying, "Tools are good to do refactorings. Without them, people aren't too religious about it. But don't trust the tools too much; baby-steps and test verifiction is still crucial."

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.

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.

Refactoring

I love refactoring… For those who has never heard about it, I can teach you, guys.. Pay attention…
You know when you do some bad things and you think: Oh s***! I really would like to change it..??
So, that's refactoring,.. Not only the thoughts,.. To tell you the truth, refactoring starts on the thoughts and keeps on making you take an attitude to change it.. And that's awesome,.. You can do it whenever you want,.. Actually, you are free, did you know? There is no guards, there is no jail, man… The life is only one and I really can't understand why you are not moving,.. Being stop is so bad,.. Being stop is the devil… That's what really means devil. Moving is life,.. You are able to commit so many mistakes you should.. Actually, it's an obligation.. Commit all mistakes you are able to do!!! The wisdom is behind each mistake we commit… It's impossible to be a wisdom person without mistakes…

I started saying that refactories have to be used in order to convert bad things in good things but it's not only bad things,.. Your yesterday's good attitudes can reflects today on a bad attitude or a kind of attitude which deserves sort of improvements,.. That's what I'd like to tell you, indeed.

It servers to the life, not only codes.

One can read good books on a specific technology (COM, UML etc) or on specific programming languages or even on different approaches to software development (RUP, OPEN etc) but every now and then a true classic comes along. Like Design Patterns 4 years ago now refactoring comes along. Every serious OO developer should own both of these books. Get your hands on Refactoring if only to read chapter 3, which summarises all the 'bad smells' that may creep into code. 21 generic examples of what is bad programming and why. The remainder of the book describes numerous techniques (refactorings) for changing existing code in order to remove the 'smell'. Most refactorings are accompanied with some UML, which should be enough to get the idea, and they are then further described in Java. What makes this great a book is that it can be used as a reference very easily since its design was well thought out for this purpose with a comprehensive index and tables matching smells and respective refactorings. If any of this rings a bell to CODE COMPLETE readers it should cause the ideas are very similar but very much updated here. Fowler's writing style makes once again for easy, pleasant reading. Unreservedly recommended.

Refactoring is no more than restructuring code by altering its internal structure without changing its external behavior. At first sight, it could seem that such innocuous transformations (from an external point of view) would not deserve a whole book. However, refactoring is one of the key techniques behind the success of agile software development.

Among other things, refactoring makes supple designs and test-driven development possible. When properly used, it helps in software maintenance (see Michael Feathers' "Working effectively with legacy code"). It also provides tangible benefits in debugging: if you don't find the error, that's because you don't understand what the code does, so making it clearer will always help.

Although you might find Fowler's catalog of refactorings rather dry and many integrated development environments automate them nowadays, thus making Fowler's recipes unnecessary, it is fair to recognize the milestone this book marked when it was first published a few years ago.

I just finished reading this book (and I am going to read it again and again.) Martin, you are the man! Your style is so amazing. But mostly, this is a book I am going to recommend to my co-workers, my friends, my family and anyone who wants to write good code. It's never too late to start. This book is just unbelievably great. There are so many examples. I program in Java and C++ and it was a time when I was at lost with my own code, let alone the code of others, only a few weeks after writing it. Not anymore! I have downloaded the JUnit and CPPUnit from the author's page and used them in all my projects with the refactoring methods described in the book. And then I went through this period of depression as I understood how much time and efforts I have lost in my existence without the fundamental guidelines described in this chef d'oeuvre. I feel better now. Thanks you!

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.

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.

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

Refactoring, says Fowler in his preface, is improving the structure of the code without changing the behavior at all. His book certainly offers an organized way to do that, with examples and then an entire second half of the book which is a reference of refactoring patterns. I can recommend reading the first half of the book (methods) and then keeping it around as a reference when needed.

But as a constant daily method, I think it claims too much. "Improving the design of the code after it has been written," is still difficult, even if you have a book of refactoring patterns. And Fowler rightly makes having a strong unit testing suite a requirement.

So I can say: read the book so that if you find yourself doing refactoring, you won't have to reinvent the wheel. But don't get your hopes up that refactoring is a substitute for good design and clear coding, as measured and improved through review by trusted co-workers.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refractor you are improving the design of the code after it has been written.

When I first got this hardcover in December 2000, there were no integrated development environments (IDE) that would have easily allowed applying refactorings like Extract Method or Inline Method. Now, in 2008, any IDE like Delphi allows to refactor in one click. So now this book is even more valuable than it was at a time of first publication.

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).

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.

Like most Martin Fowler books, this was enlightening. Keep it as a reference in your personal software developer library.

Not a five star for me just because you clearly risk exposure to information overload. And the book could have been better organized, I wasted time to do a "cheatsheet" for me, combined with what we have already online.

Refactoring is so important and many companies don't put enough emphasis on refactoring. This book provides a great introduction to what refactoring is and a great reference for how to refactor. The first few chapters are crucial for every computer programmer and project manager to read. These first chapters will clearly explain how and why you need to be refactoring. The later chapters go through various refactoring patterns. These later chapters will be very useful to programmers with less OO programming experience but may be less useful to many programmers. Regardless, the book is well worth it even if you only read the first few chapters.

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.

Then read this book - it contains great tips and hints for how to be a better developer by making your code (or someone else's code) more easily maintainable. For example
> Remove duplicated code
> Write smaller classes "Do one thing and do it well"
> Only expose methods that need to be exposed
> re-write complicated expressions by introducing temporary variables with names that explain the purpose
and so many others. Particularly great for those left maintaining code written by someone else who thought a class containing 2,500 lines of code is fine.

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.

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".

No kidding, this book completely changed the way I code and think about coding. OK, I'm not one of your A-list, published OO authorities, but I've been coding for a long time, and this changed everything.

It's called "Refactoring", but along the way you see that it explicates an entire philosophy of OO design. The whole thing is presented so engagingly and with an appealing tongue-in-cheek sly wittiness that you almost read it like a novel or memoir. And what is presented is profound, fascinating and totally practical. You can apply it today.

(I came here to plug the book, which I had just reopened for the thousandth time, and just decided I also ought to let y'all know that I was inspired by this to write a refactoring tool for VB6, CodeShine).

I was referred to this book from a colleague after a quick discussion on "Replace temp with Query" in our projects code base.

I thought I knew it all as a software developer, but reading this book, I soon came to realize that as a software developer I was leaving a legacy of code that was not at the standard it should be.

This book opened my eyes to some really simple concepts, for example, when trying to understand code someone else has written (or yourself in some cases) take the time to re-factor the code (i.e. Extract Method) so that the code is understandable, since most of the work is spent in trying to understand the code in the first place. This concept of modifying code as you understand it is superb.

I must say I was skeptical at first but the benefits are really starting to show. This book is written with the knowledge of Martin Fowler, and as such is written with experience of what it is like to be a developer in a commercial environment, for example, trying to explain to management the trade-offs of re-factoring first instead of "tacking on" that new feature. Something that is difficult in any environment.

This book will by no means solve your problems, but it will empower you with a new found love to make the IT project(s) you work on better (i.e. not thinking of the now but the future) practice some of the smaller concepts this book presents on a daily basis and the rewards are well worth it, break those bad habits today.

Despite refactoring all day, this book finally taught me how, all with the first chapter. You do it incrementally, until you can make the "real" change that you wanted to make trivially, or easily. Or if there's a code smell, why, you refactor that out just to get rid of its smell. Affected my programming style quite a bit, in a good way.

If you have a certain knowledge about refactoring, this book might not be as valuable as if you were new to the concept.

However, it contains a deep enough introduction and a reference to every important refactoring methods. For each of those methods, "pros/cons" and "when/when not" are listed to help you make the right choice.

Most of the examples are really simple since it is easier to write, but it is intended to be applied to complex cases.

I do recommend it, unless you have over 10 years of experience in refactoring already.

If you have a certain knowledge about refactoring, this book might not be as valuable as if you were new to the concept.

However, it contains a deep enough introduction and a reference to every important refactoring methods. For each of those methods, "pros/cons" and "when/when not" are listed to help you make the right choice.

Most of the examples are really simple since it is easier to write, but it is intended to be applied to complex cases.

I do recommend it, unless you have over 10 years of experience in refactoring already.

From time to time, but in truth rarely, an author write a book that change our mind about code or software process. From my point of view, this is the 2nd book like that in this decade (the first was Design Patterns). It outline especially that code and design that works isn't enough. He also describes formally things that I do (and thousands programmers) for years, but silently. Even if expressed in Java, the book is usefull in all OO languages. Just get it!

Nearly 15 years old, you would think this book (in fact this idea) would be well enough understood to be redundant. Sadly this book remains as relevant today as when I first read it all those years ago.

It's much better to read the original edition even if you have to translate JAVA into Ruby.
There are so many errors.
Many refactorings start at the end of a page and are immediately cut by the page. It is a very unpleasant reading experience.
Strongly recommend go for the classic JAVA edition.

Refactoring is something that I was doing subconsiously everyday at my work as a coder. When I got the book I had an "aha!!!" feeling. Most of the stuff I was doing had labels and names :-)

This helped me a lot, since it provided me with the language I needed in order to be able to convey to my colleages what I was doing or what I needed them to do.

I think that refactoring as a concept is far more important than design patterns for your everyday work. So far I have only needed design patterns 2 or 3 times, while refactoring I do day in day out.

A reasonable amount of the refactorings listed are helpful and I learned good things from reading about them. However, too many of them are basic programming heuristics that many of us know already. I would have liked the authors to spend more time on OO design centric refactorings or at least more advanced general programming refactorings. This book would be helpful to the beginner, but more experienced programmers probably already do many of these refactorings on their own.

Along with Design Patterns, Refactorings is a significant step forward in software engineering. I actually found this book to be more useful than the popular Design Patterns book. Most software developers do not write new code from scratch. Instead they have to enhance and maintain code written by other developers. This book provides many useful techniques to make this job easier. To some degree, I found I was already using techniques like these in my own day-to-day work. This book, like Design Patterns, collects these techniques and makes them available to everyone.

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*

Refactoring is important for code support which is easily neglected by most projects. The techniques covered not only essential for post-implementation but also it's the pre-requisites of developing a robust and managable code. It's easy-readable and highly recommendable to all level of developers.

One of my clients went through a refactoring project last year and recently this project has been revived to see if it can be incorporated with an SOA project that I am now involved with. Studying how to design services for a legacy environment while also lookint at refactoring some of the existing legacy components we have in place raised a lot of issues.

I won't bore you with the details of our project but I will mention that this book was very helpful in nailing down exactly what our options to refactoring are. It focuses a lot on theory and has some insight as to where this trend is going. I learned that refactoring is *not* extending as much as it is improving what you already have.

If you're interested in refactoring from a project point of view, then this is a great resource.

Very understandable and lots of examples. This book gives you a nice hands-on toolset of how to improve the design of legacy code. It gives a nice alternative to haveing the "perfect" design and makes iterative programming legitimate.

If you write software for a living, and especially if you use an OO language, you should read this book. It's a guide on how to make your software better while keeping the risks to a minimum -- an essential task.
The writing is great; humor turns potentially dry examples into easy to read and comprehend lessons.

This book presented a very methodical approach to refactoring that I found very useful. In practice, it can be tricky to follow. The author's assertion that junit tests are necessary is at once truthful and a little impractical. Overall, the book is an easy read and a great beginning into cleaning up code.

When I first started reading this book, I Laughed. Having garnered a reputation as a "Mad Slasher" of badly written code (say, 700 line programs down to 150 lines or less), it was wonderful to see the principles I'd learned over the years codified into a readable catalog of techniques that should be in everyone's arsenal. Required reading for those new to OO development, and a new vocabulary (similar to what "Design Patterns" did) for everyone to share their insights. BRAVO

This book will change the way you think about and working with exisiting code. It'll teach you that changing/modifying software is a fact of life. Fowler does a great job of describing how to improve the design of existing code by performing various refactorings. Various design patterns are mentioned throughout the text so I recommend picking up the GoF "Design Patterns" book for reference (if you don't already have it).

I liked Fowler's book so much that I've picked up a few of his other books and am re-reading this one.

What impressed me most about this book was its attitude. Granted that the book expertly leads us through refactoring of smelly code; and granted that the catalog of refactorings are full of interesting insights. But still and all, it was the attitude that the value of a module was not maximized simply by making it work that really struck home.
You can vastly improve a module without changing its function whatever. Morevoer, such function preserving, structure improving, changes are a normal and essential part of every engineer's role.

First of all, this book is good to understand the meaning of refactoring and its techniques. If you are a beginner programmer, the book is quite helpful to know how to do refactoring, and why and when to do it.
However, the problem is the book is a "book". Many programmers may feel familiar with stories and techniques in the book. The techniques in the book, though, are not exceptional, unfortunately. For example, the book explains how to make a temporary variable or how to eliminate it for a couple of pages! This kind of thing is a common work for programmers. Many don't have to learn that.
One of problems of refactoring for experienced programmers is that refactoring means not add features but "change" existing code. Although giving benefits, refactoring gives some problem. For example, when working as team, it is hard to even change the name of method because the change often causes conflict among sourcecode. The book doesn't give any solution of this problem.
In conclusion, I don't recommend this book for experienced programmers.

What is better? Replacing delegations with inheritance or replacing inheritance with delegation?

The answer is the ultimate answer to most software engineering decisions: DEPENDS, there is always a trade-off that has to be analyzed according to the context! This book addresses those trade-offs very well.

Moreover, I like the examples in the book, good to use in class when teaching. They generate interesting discussions.

This is another fabulously written book by Martin Fowler. Concepts are described in excellent detail, yet simple to understand. The first chapter alone is worth the price of the book. It not only describes numerous means of improving existing code, it abets the understanding of the full potential of the object-oriented paradigm and will significantly improve the way you write new code as well.

This book changed the way I think about software development. It's a little old, but the principals still apply. The author writes in a simple way where anyone, reguardless of background can understand. The termonology the author uses is priceless and creates a way for programmers to speak to one another in an effective way. I would recommend it to any software developer, regardless of career stage or background.

I got this book at the recommendation of another book (Ken Henderson's Guru's Guide to Stored Procedures) and was simply blown away by it. I have been preaching the lessons this book tries to teach for years. Now I finally have a text I can point people to to say "Hey, this code is really broken even though it still runs. We need to fix it!" Thank you, thank you, thank you for such a wonderful book.

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

A great book that uses clean code examples to illustrate powerful concepts. It is good at showing critical OOP concepts as well as refactoring techniques for cleaning up code. Reading this will most likely make you a better programmer.

This book makes a wonderful reference and should be on every developer's shelf. I gain new insights whenever I pick it up even on concepts that I thought I knew.

Read the first several chapters when you first get this book - they are well-written and eye-opening. The remainder of the book is a catalog of Refactorings, which I recommend skimming initially and periodically poking through to refresh your fundamentals and pick up on the hidden gems.