Amazon.com: Customer Reviews: Refactoring: Improving the Design of Existing Code
Amazon Vehicles Up to 80 Percent Off Textbooks Amazon Fashion Learn more Discover it $5 Albums Fire TV Stick Happy Belly Snacks Totes Amazon Cash Back Offer TheKicks TheKicks TheKicks  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Starting at $49.99 All-New Kindle Oasis Florida Georgia Line Shop Now

Format: Hardcover|Change
Price:$47.25+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item


There was a problem filtering reviews right now. Please try again later.

Showing 1-10 of 147 reviews(5 star). Show all reviews
on November 11, 2002
A little while back I was introduced to a word I had never heard before, Refactoring. I was told to
get Martin Fowler's book and read it so I could gain a better understanding of what Refactoring
was. Well folks, I would classify this book as a 'Hidden Treasure'.
Although it is not a flashy or well known title, I believe its impact can be much deeper and long
lasting than many of the mainstream, more popular technology books. The underlying theories
that it teaches can be applied for years, even when languages change.
There are only a couple of things I would change about this book, which I will mention below.
Preface
The Preface it brief enough, and gives the definition for the word Refactoring. This is a good thing
because right form the start you get the true definition of Refactoring. In short, refactoring is the
process of changing code to improve the internal structure, but not changing the external
behavior.
Chapter 1: Refactoring, a First Example
In this chapter Mr. Fowler tries to start by showing a simple Refactoring example. The problem is
that the chapter then goes on for 50+ pages. Mr. Fowler explains his reasons for doing this, but I
think that a simple example should have been much simpler. Especially when it is in the first
chapter of the book. It's not that this isn't a good chapter. I feel it's just too soon in the book. I
would have put it at the end.
Chapter 2: Principles of Refactoring
This is an excellent chapter. The definition of Refactoring is discussed as well as the following
questions: Why should you refactor? When should you refactor? What do I tell my manager? This
last question may seem funny, but when you read this chapter you will understand why it is in
there. This chapter also discusses common problems that occur during Refactoring, and
Refactoring and performance.
Chapter 3: Bad Smells in Code
In this chapter things that cause code to 'smell' are discussed. When code 'smells' it could be an
indicator that refactoring is needed. 22 different 'smells' are discussed. My favorites were
Duplicated Code, Large Class, and Lazy Class. This is a chapter full of awesome hints.
Chapter 4: Building Tests
Building tests is an important part refactoring. Refactoring is done in small steps, and after every
step you should test. In this chapter the discussion covers the processes and methodology of
applying tests during refactoring.
Chapter 5: Toward a Catalog of Refactorings
This chapter is a quick setup for chapters 6 to 12. Mr. Fowler explains his method for cataloging
the individual refactorings. What is pretty amazing is that he has taken a lot of time naming and
detailing each refactoring.
Chapter 6: Composing Methods
One of my favorite chapters. Mr. Fowler opens by saying, "A large part of my refactoring is
composing methods to package code properly." This chapter is all about that. 9 total refactorings
are explained. My favorite ones are Inline Method and Extract Method.
Chapter 7: Moving Features Between Objects
Sometimes you need to move things from one object to another. This chapter discusses the art of
moving features between objects. 8 total refactorings are discussed and detailed. My favorite
from this chapter is Extract Class.
Chapter 8: Organizing Data
A very large chapter that discusses in meticulous detail 16 refactorings that will make it much
easier to work with data. One thing that becomes very obvious in this chapter is that certain
refactorings can go either way. What I mean is illustrated by these two: Change Value to
Reference and Change Reference to Value. So some refactorings are not just one way deals. It
just depends on the situation.
Chapter 9: Simplifying Conditional Expressions
This is a very useful chapter since conditional logic is a common occurrence in the programming
world. Because conditional logic has a tendency to get very complex, this chapter has 8
refactorings that will help you simplify things.
Chapter 10: Making Method Calls Simpler
The 15 refactorings in this chapter help teach us how to make method calls easier to deal with.
They range from the very simple Rename Method to the more complex Replace Constructor with
Factory Method.
Chapter 11: Dealing with Generalization
Here are 12 refactorings dealing with the situations that arise from generalization. Inheritance,
Delegation, and Interfaces are some of the topics discussed.
Chapter 12: Big Refactorings
Kent Beck co-wrote this chapter with Mr. Fowler. They discuss what they call the 4 Big
Refactorings: Tease Apart Inheritance, Convert Procedural Design to Objects, Separate Domain
from Presentation, and Extract Hierarchy. These refactorings are of a more all-encompassing
type than the smaller individual refactorings from the preceding chapters. The co-authors do a
great job at putting in a nutshell what would normally take very long explanations.
Chapter 13: Refactoring, Reuse, and Reality
William Opdyke writes this chapter. He discusses his experiences with refactoring as well as
other subjects like why developers are reluctant to refactor and reducing the overhead of
refactoring. This chapter is an excellent 'putting it all together' chapter, and really helps put into
perspective the ideas that the book teaches.
Chapter 14: Refactoring Tools
Don Roberts and John Brant co-author this chapter. They discuss, as the chapter title would
indicate, refactoring tools.
Chapter 15: Putting It All Together
Kent Beck gives a quick 4-page wrap up.
One other thing I would change about the book is that I would want there to be examples in other
languages besides Java. I have practically no Java skills. For me the book would have been an
easier and faster read if it would have had examples in VB.net. Fortunately I understand enough
to get the idea of what is being taught, and that is the most important point.
Well as I said above, this book is really what I would consider a 'hidden treasure'. The things
discussed will help many people write better, more understandable code for years to come. I
would give it a 9.5 out of 10. It is well worth the {price}
0Comment| 115 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 17, 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.
0Comment| 28 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 18, 2000
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.
0Comment| 38 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 28, 1999
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.
0Comment| 17 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 13, 2003
I've known about this book for over a year. Initially, I thought it was about re-engineering legacy systems. I don't do that, so I didn't give it much thought. Over the past year, I have stumbled across repeated references to this book. Everyone seems to cite it, and now I understand why.
It's very easy to fall into 'analysis paralysis' when doing object design. A commonly heard complaint is "I have created 27 different class diagrams, and 42 separate sequence diagrams, but I can't seem to get any code written..." XP's popularity is due, in part, becuase it get's you into action--you begin writing code immediately, instead of creating diagrams for weeks (or months) on end. XP's motto could be "just do it!"
But how does one reconcile this "code first, ask questions later" mentality with an acknowledged need to at least do some design work? In "Refactoring", Martin Fowler provides the answer. His prescription is to create some code to get something working, then look at the code to see how it might be improved-- refactor it.
In Fowler's view, you won't really understand the problem until you have coded it, so instead of spending the next three weeks trying to find the perfect pattern for your next task, forget the pattern, and get some code going. Once you've got something workable, then think about patterns you might back into from your existing code.
Of course, that's a gross oversimplification of the process, but it gives a flavor of the ready-fire-aim process that 'Refactoring' is built around. And it seems to work--even people who don't buy into other core practices of XP seem to have adopted refactoring as a central element in their process.
The catalog of refactorings that the books provides are a first class reference on how to clean up particular problems. But to me, the most valuable part of the book is its first fifty pages.
Fowler starts the book with a simple, but ugly, example, that he proceeds to refactor, step-by-step, into something rather elegant. If you like to learn principles first, you might want to read the second chapter before going through the example, but I found it a very valuable exercise. I recommend coding the example in your language of choice, then refactoring along with Fowler as you work through the example.
There is a temptation to relegate refactoring, like testing, to simply another development technique. But like testing, refactoring is at the core of a development philosophy: "I know I'm not going to get it right on my first pass, so I'll be satisfied with making it as right as I can. Having done that, I'll have a much better idea how to make it better, and I will. But time's a' wasting, so I need to get moving."
This philosophy of continuous improvement allows the developer to get into action fairly quickly, and it reduces the risk of failure-by-delay. Fowler's book is a top-notch resource that will help the developer create more flexible code more quickly. I can recommend 'Refactoring' without reservation.
0Comment| 20 people found this helpful. Was this review helpful to you?YesNoReport abuse
on September 3, 2001
I would have to give 2 thumbs up to Martin Fowler's book on Refactoring. He has addressed so many common refactorings in such a simple and elegant way that many will benefit from his work (as well as the others that helped write this book).
Martin's writing style is very relaxed and sincere. He's entertaining and doesn't complicate things as you can easily find what you need. You can tell he simply wants to make programming teams' lives easier and he has accomplished tenfold. He's not going to tell you that your an innately bad programmer or that he is a better one - he truely captivates that quality code is important and refactoring is that one big step that each organization and programmer must take to improve the quality of code.
Some of the patterns that he identifies are very common - but for completeness' sake, he includes them. Others are very insightful such as Introducing Null objects, which I've used 5 times in a single application now since I've read this book.
This is also an excellent book to accompany Design Patterns, as many of these refactorings will help you achieve design patterns in your code - it's like working them in your code in a different, systematic way.
All in all, this is a fantastic contribution to improving code and developing quality programmers in the software development industry. I would recommend this to any software professional and especially university students (where quality code is not touched on at all). It's the will of the programmer to improve their code and this is one of those books to read if you want to do that. If you want to just be an average programmer, a following in your organization and not take responsibility - then don't read this book. If you want to truely be effective in your job or entrapreneural projects, add this book to your bookshelf and read it, use it and live it.
0Comment| 14 people found this helpful. Was this review helpful to you?YesNoReport abuse
on February 13, 2004
First, a bit of information about where I'm coming from. 10 years ago I came away with a Computer Science minor but never really utilized the programming skills I'd learned in any of my subsequent jobs (Marine Biology). However, I did dabble in teaching myself C++ and loved the concept of Object Oriented programming. Recently I landed a job working with IDL (Interative Data Language - NOT Corba IDL) which was originally designed to create quick 2D and 3D plots and images for scientists. While still primarily a scientist's language, it has been adding more and more features, including Object Oriented support.
So this means, I'm now a programmer. My new boss really wants almost everything done as an OO design, which I was more than happy about. However, much of my work will be to modify/extend old code which is in every form from procedural to pseudo-OO (uses a few objects here and there but is still mostly procedural). I originally convinced the boss to pick up this book by pointing out the section on converting Procedural Code to OO. Turns out this section is very short, but gives an overview of how to do it using the other refactorings in the book. So it's helpful there.
One place I haven't seen it mentioned in many reviews is the benefit this book can have for someone new to programming professionally (note, I do NOT mean to imply that this is a beginner programmer's book, you should have a good understanding of OO programming already). It has already had many benefits for me:
1. Smells in Code: I love this section. As everywhere in the book, it applies directly to poring through old code and picking out the 'smells' present that indicate poorly structured code. But it's also as valuable in pointing out what to watch for as you write a new program. The book does advocate a design/refactor approach, and this is the best example of it. As you design, you notice one of the 'smells' creep into your code, and you can refactor it then and there. This has been of immense value to me in my first programming projects.
2. Advocation of testing: I already have Kent Beck's "Test Driven Development" and utilized some concepts from it, but "Refactoring" also talks about testing, and it seems to flow much better for me in Fowler's book as far as understanding how to use tests. It 'clicked' when he mentioned that most of the time spent creating a program wasn't design/programming, but rather tracking down a bug. Combining quick and frequent tests on new refactorings (or just new bits of code added in) focuses the programmer very swiftly on just what went wrong. The longest I've ever spent puzzling out a bug so far on my first major project has been 30 minutes, and that's because I forgot a return statement. As soon as I got up, took a break and sat back down it was obvious. Most other bugs have been along the lines of "run the test, watch it crash, fix within 2-5 minutes".
3.Ideas on how to structure code I haven't written yet: Maybe "Design Patterns" is a better book for this, but everytime I've looked at it, it overwhelms me. "Refactoring" somehow seems to put into focus more clearly how to fix a problem that's stumping me. For example, the program I'm working on requires two ways of creating a new object. One creates it directly from a file, one creates it from a GUI where all data is entered, and then added by hitting the 'create' button. I got the 'initFromFile' constructor working nicely and then proceeded to start work on the 'initFromGUI', recreating most of the steps until I hit the point where the object had to create a linked list based on the number of swimbladders (each of which is an object in the linked list) within the main fish object. Long story short, I thought about creating the object separately and just passing it in as a parameter, but besides requiring more knowledge of the object the GUI was working with than I wanted the GUI to have, it also led to one Init call with a huge list of parameters). So I flipped through "Refactoring" and found "Duplicate Observed Data" which described the exact problem I was trying to solve and goes into enough detail on using the 'Observer' Pattern that I was able to get my code to work in a much cleaner fashion than I would have otherwise.
4. Teaches the 'obvious' to new programmers: Some of the complaints I've read involve "Well, any real OO programmer knows this already, it's a waste of space to include that." In my case this is not necessarily true. Some of the refactorings are indeed obvious to me. Others that are obvious to others are not obvious to me. Even more important, you will see some of these 'obvious' things in previously created 'legacy' code, and this book will allow you to spot it.
0Comment| 13 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 3, 2000
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.
0Comment| 9 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 20, 1999
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?
0Comment| 12 people found this helpful. Was this review helpful to you?YesNoReport abuse
on February 16, 2007
Refactoring: Improving the Design of Existing Code is one of those amazing books that every professional developer should have on their book shelf. The bulk of this book is a catalog of refactorings, but there is more to it as I will explain below.

In case you aren't aware of what refactoring is, I'll give you Fowlers definition.

"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." For the most part this means cleaning up your existing - yet working - code. It involves anything from renaming a method to be more concise with the purpose of that method, to breaking up switch statements into a polymorphic structure. There are many different techniques used to refactor your code, which is what you learn in this book.

Right off the bat Fowler throws you into a small sample application that is poorly designed. He then takes you through a few different refactoring techniques that improve the design of this simple application. Right from the start you see how effective refactoring can be. From there he goes into topics such as how to detect "bad smells" in code. This chapter is particularly informative and entertaining. You also learn a little bit about testing. After the introductory chapters you begin to dig into a deep catalog of refactorings. Each one is named. Like design patterns - naming the refactoring and building a vocabulary really helps in communicating thoughts and ideas.

The catalog of refactorings is extremely useful. They are structured so that each refactoring has a name, a motivation, the mechanics and a simple example. This is very effective. As I said earlier, the name is useful because it helps build your programming vocabulary and it helps in communicating thoughts and ideas. The motivation explains why the refactoring should be done and when it should/shouldn't be used. The mechanics provide a step-by-step description of how to carry out the refactoring and the example shows a small example of the refactoring in use. All examples are written in Java 1.1.

Although the examples are written in Java the book is still very good for any developer. Developers that have never written a line of code in Java, C++, C#, or anything similar may have a little bit of a tougher time working through this book. Luckily most examples are very small and simple so even if you fall into this category you shouldn't have too much of a learning curve. Some of the code is a bit outdated and can be done a bit better now-a-days but what do you expect? This book was written 8+ years ago! Times have changed. The ideas are still very relevant though, which is what makes this book so timeless.

Martin Fowler books are always a joy to read. His writing style is humorous, yet often very blunt and to the point. Just like UML Distilled, he is able to communicate a lot of ideas into a very short amount of space - the book is a bit dense in other words, which is very good in my opinion. Martin Fowler does not beat around the bush and he has very strong opinions on certain topics. Unlike a lot of books you read, he actually writes with personality. I have a hard time putting his books down. Here is an example of the type of verbiage he uses...

On how comments can be a "bad smell":

"Don't worry; we aren't saying that people shouldn't write comments. In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant." - Martin Fowler. Here he is talking about how people use comments to hide bad code, or "bad smells".

I highly recommend this book. If you are a professional developer or plan on becoming one then click the "Buy Now" button without second thought. This is one of those rare books worth its weight in gold - I would spend $100.00 on a book like this if I had to.
0Comment| 8 people found this helpful. Was this review helpful to you?YesNoReport abuse