countdown boutiques-francophones scflyout Learn more Pets All-New Kindle Music Deals Store sports Tools

Customer Reviews

4.6 out of 5 stars
4.6 out of 5 stars
Format: Hardcover|Change
Price:$69.58+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

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

on July 9, 2004
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.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 22, 2004
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.
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on October 28, 1999
Matin surely presents a good strategy which is easily proved in the book. However I do not think it is a big enough issue to justify the whole book. He filled the content with many basics of object oriented and good programming practice. While many are not familiar with patterns and these techniques are not used as much as they should, I expect better material from Martin.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on April 27, 2004
This remarkable book is the next logical step after 'Design Patterns'. In fact, it would be fair to call this 'Re-Design Patterns'.
It follows closely in the DP community's habit. For each way of improving a program, it systematically presents a name, set of conditions when it does or does not apply, and (unlike most DP books) clear, demonstrative examples and variations. As with design patterns, many of these recommendations have a sense about them of "I already knew that." That's a good thing - it means you bring familiarity to the reading, instead of starting cold. That lets Fowler get on with his real business, which is to systematize the knowledge and regularize the process of choosing a technique to use.
I hope this follows another habit of the DP community, too: the public cataloging, collecting, and sharing of new techniques for refactoring. I could add bunches to the list, as I'm sure any other seasoned programmer could. One thing is distinctive about the refactorings: the number that come in matched, opposite pairs. This just emphasizes the context dependency of refactoring - each technique has its place, but is not appropriate in all places. Also, paired opposites effectively double the number of choices a practitioner has.
Design patterns are very helpful, almost like power tools for programmers. Face it, though: initial design and implementation are only 1-10% of a large program's life. Maintenance, extension, and re-design are the other 90-99%. DP techniques get a program started, refactorings keep it going.
If you started programming before most of your co-workers were born, you may not get the most out of this book. Get it anyway, and make sure the young pups read it. This knowledge needs to be spread.
0Comment|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|Was this review helpful to you?YesNoReport abuse
on August 19, 2003
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."
0Comment|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|Was this review helpful to you?YesNoReport abuse
on February 6, 2003
This book is a classic, it changes the way you think about programming.
If you are two or three years into your programming career, you have probably had the urge to take a project and redesign it from scratch. You may have said to yourself "if only I had known about x methodology or y framework, this code could have been a lot cleaner." Sometimes these experiences can amplify a programmer's inhibitions. An inhibited programmer is often a less productive one.
Refactoring eases a programmer's inhibitions in two ways. First, it shows why there is no need to create a PERFECT design up front. If better ideas emerge later, they can be integrated safely and securely. Second, the book provides methods for changing existing code using step-by-step "recipes" for dozens of refactoring scenarios. These recipes guide you through the tasks in such a manner that all possible holes exposed along the way are protected.
Another small gem of this book is a guide for identifying "code smells". Code smells are pieces of code that compile, test and run correctly but nonetheless look bad or ugly. The section on code smells help you pinpoint what is ugly about it. As they say, "a well-stated problem is a half solved one".
After reading this book you will finally understand the XP edict "Refactor early and often".
0Comment|Was this review helpful to you?YesNoReport abuse
on January 20, 2003
Before I read this book, when someone mentioned refactoring, I would imagine it would be either "code cleanup", e.g., refactoring out the common behavior to the base class or a subroutine or "total redesign", e.g., breaking up current architecture, all these two can be avoided and unnecessary if we analyze the problem right, abstract the model right, architect the application right, design and code right.
I am a bigot of OO technology, design patterns, iterative software develop process from analysis, architure, design, construction to testing, and I know to get all the above things "right" would be very hard if not impossible at all. But that is what our designers and developers' job, facing the challenge right? So how is refactoring going to affect us as designers and develoers?
The first chaper(example) is particular interesting and attractive to me, as it just pointed out some signs of "evilness" in the design, e.g., a lot of tag/case for runtime type checking, responsibility was assigned to the wrong class, inaccurate/insufficient abstraction. Actually, it is this chapter which made me decide to get the book and see how the author would correct these problems. Mr. Fowler did excellent job on this topic.
Most Software developers may not have the luxuery to always work on the new project from start, we may inherit legacy codes which was not designed to solve today's problem, even an initial good design could go decayed, be it lack of documentation, insufficient of communication, different levels within the develop team, etc. Now with this book, we can take a breath and start refactoring the existing design/code to make it solve today's requirement, to even make it extensible for tommorrow's change. Initial design is no longer a huge burden, as it can be refactored, extended to fit the unseenable things when it was made.
The only thing in this book that annoys me is the verbosity of the refactoring steps in each chapter. It exposed to much details. I think the text decription and UML notation would be enough for any experienced developers to see the design problems and how to correct them. All those steps would only serve the needs for refactoring tools developers. But even with all the details, it is a "light" reading :-)
0Comment|Was this review helpful to you?YesNoReport abuse
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.
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
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 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|Was this review helpful to you?YesNoReport abuse