countdown boutiques-francophones Beauty Home Kindle Explore the Amazon.ca Vinyl LP Records Store sports Tools

Customer Reviews

4.6 out of 5 stars
100
4.6 out of 5 stars
Format: Hardcover|Change
Price:$51.99+ 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 March 31, 2017
An idea that the code executed by a computer can be written in more or less readable way is on the surface. Making an art out of it and digging into an idea of smooth transformation is a revelation. This is an easy readable book with a potentially big impact on happiness in your coding life. And even though I do not agree with all suggestions I feel that the new coding style will become my second nature. 5 starts.
0Comment|Was this review helpful to you?YesNoReport abuse
on August 19, 2016
Reference and learning.
Convincing and can be applied right away.
Has short term and long term refactoring.
Aimed at Java but could be applied to most object oriented code and includes some procedural too.
has info on how to take this further.
0Comment|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 March 15, 2000
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
0Comment| 5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 5, 2000
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.
0Comment|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|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 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 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