|
Refactoring: Improving the Design of Existing Code (Hardcover)
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
| Category:
Software development, Programming, IT, Technology |
| Market price: ¥ 578.00
MSL price:
¥ 548.00
[ Shop incentives ]
|
| Stock:
Pre-order item, lead time 3-7 weeks upon payment [ COD term does not apply to pre-order items ] |
MSL rating:
 Good for Gifts |
| MSL Pointer Review:
Full of code examples in Java, easy to read and right into target, this book is a masterly and comprehensive reference on refactoring. |
| If you want us to help you with the right titles you're looking for, or to make reading recommendations based on your needs, please contact our consultants. |
Detail |
Author |
Description |
Excerpt |
Reviews |
|
|
|
Author: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Publisher: Addison-Wesley Professional
Pub. in: June, 1999
ISBN: 0201485672
Pages: 464
Measurements: 9.5 x 7.6 x 1.4 inches
Origin of product: USA
Order code: BA00534
Other information: 1st edition
|
|
Rate this product:
|
|
- MSL Picks -
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 Refactoring 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.
(From quoting an American reader)
Target readers:
Software developers, Software development project leaders and managers, Students of Computer Science and University teachers.
|
|
- Better with -
Better with
Rapid Development
:
|
|
Customers who bought this product also bought:
 |
Code Complete, Second Edition (Paperback)
by Steve McConnell
Focusing on actual code construction, but touching on every aspect of software engineering including psychology/behavior, this book is an essential reading for every and all developers. |
 |
Peopleware : Productive Projects and Teams, 2nd Ed. (Paperback)
by Tom Demarco, Timothy Lister
The book made a clear and compelling augument that the human factor, not technology, makes or breaks a software development effort. |
 |
Rapid Development (Paperback)
by Steve McConnell
A succinct, well organized and must-read collection of the lessons learned and best practices in software engineering over the last three decades. |
 |
The Pragmatic Programmer: From Journeyman to Master (Paperback)
by Andrew Hunt, David Thomas
A classic reading on programming ranking with Code Complete and The Mythtical Man-Month. |
|
|
Martin Fowler is the Chief Scientist of ThoughtWorks, an enterprise- application development and delivery company. He's been applying object-oriented techniques to enterprise software development for over a decade. He is notorious for his work on patterns, the UML, refactoring, and agile methods. Martin lives in Melrose, Massachusetts, with his wife, Cindy, and a very strange cat. His homepage is http://martinfowler.com.
Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.
John Brant and Don Roberts are the authors of the Refactoring Browser for Smalltalk. They are also consultants who have studied both the practical and theoretical aspects of refactoring for six years.
William Opdyke's doctoral research on refactoring object-oriented frameworks at the University of Illinois led to the first major publication on this topic. He is currently a Distinguished Member of Technical Staff at Lucent Technologies/Bell Laboratories.
|
|
From the Publisher:
As the application of object technology-particularly the Java program- ming language - has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend. Increasingly, software system professionals are discovering just how difficult it is to work with these inherited, "non-optimal" applications. For several years, expert-level object programmers have employed a growing collection of techniques to improve the structural integrity and performance of such existing software programs. Referred to as "refactoring," these practices have remained in the domain of experts because no attempt has been made to transcribe the lore into a form that all developers could use… until now. In Refactoring: Improving the Design of Existing Software, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process.
With proper training a skilled system designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one. Each refactoring step is simple-seemingly too simple to be worth doing. Refactoring may involve moving a field from one class to another, or pulling some code out of a method to turn it into its own method, or even pushing some code up or down a hierarchy. While these individual steps may seem elementary, the cumulative effect of such small changes can radically improve the design. Refactoring is a proven way to prevent software decay.
In addition to discussing the various techniques of refactoring, the author provides a detailed catalog of more than seventy proven refactorings with helpful pointers that teach you when to apply them; step-by-step instructions for applying each refactoring; and an example illustrating how the refactoring works. The illustrative examples are written in Java, but the ideas are applicable to any object-oriented programming language.
|
Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higher-level classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn't suit all the subclasses, however, and was overridden quite heavily. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.
The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn't seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.
The consultant had also shown the programmers who had worked on the hierarchy what was going on. The programmers were keen and saw the problem. They knew that it wasn't really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functiona- lity. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.
The project management was not pleased. Schedules were tight and there was a lot of work to do. These two programmers had spent two days doing work that had done nothing to add the many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more "pure" a bit more "clean." The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn't already do.
How do you feel about this story? Do you think the consultant was right to suggest further clean up? Or do you follow that old engineering adage, "if it works, don't fix it"?
I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance.
The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software.
What Is Refactoring?
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 refactor you are improving the design of the code after it has been written.
"Improving the design after it has been written." That's an odd turn of phrase. In our current understanding of software development we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.
Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.
With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.
What's in This Book?
This book is a guide to refactoring; it is written for a professional programmer. My aim is to show you how to do refactoring in a controlled and efficient manner. You will learn to refactor in such a way that you don't introduce bugs into the code but instead methodically improve the structure.
It's traditional to start books with an introduction. Although I agree with that principle, I don't find it easy to introduce refactoring with a generalized discussion or definitions. So I start with an example. Chapter 1 takes a small program with some common design flaws and refactors it into a more acceptable object-oriented program. Along the way we see both the process of refactoring and the application of several useful refactorings. This is the key chapter to read if you want to understand what refactoring really is about.
In Chapter 2 I cover more of the general principles of refactoring, some definitions, and the reasons for doing refactoring. I outline some of the problems with refactoring. In Chapter 3 Kent Beck helps me describe how to find bad smells in code and how to clean them up with refactorings. Testing plays a very important role in refactoring, so Chapter 4 describes how to build tests into code with a simple open-source Java testing framework.
The heart of the book, the catalog of refactorings, stretches from Chapter 5 through Chapter 12. This is by no means a comprehensive catalog. It is the beginning of such a catalog. It includes the refactorings that I have written down so far in my work in this field. When I want to do something, such as Replace Conditional with Polymorphism (255), the catalog reminds me how to do it in a safe, step-by-step manner. I hope this is the section of the book you'll come back to often.
In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. Chapter 13 is by Bill Opdyke, who describes the issues he has come across in adopting refactoring in commercial development. Chapter 14 is by Don Roberts and John Brant, who describe the true future of refactoring, automated tools. I've left the final word, Chapter 15, to the master of the art, Kent Beck.
Refactoring in Java
For all of this book I use examples in Java. Refactoring can, of course, be done with other languages, and I hope this book will be useful to those working with other languages. However, I felt it would be best to focus this book on Java because it is the language I know best. I have added occasional notes for refactoring in other languages, but I hope other people will build on this foundation with books aimed at specific languages.
To help communicate the ideas best, I have not used particularly complex areas of the Java language. So I've shied away from using inner classes, reflection, threads, and many other of Java's more powerful features. This is because I want to focus on the core refactorings as clearly as I can.
I should emphasize that these refactorings are not done with concurrent or distributed programming in mind. Those topics introduce additional concerns that are beyond the scope of this book.
Who Should Read This Book?
This book is aimed at a professional programmer, someone who writes software for a living. The examples and discussion include a lot of code to read and understand. The examples are all in Java. I chose Java because it is an increasingly well-known language that can be easily understood by anyone with a background in C. It is also an object-oriented language, and object-oriented mechanisms are a great help in refactoring.
Although it is focused on the code, refactoring has a large impact on the design of system. It is vital for senior designers and architects to understand the principles of refactoring and to use them in their projects. Refactoring is best introduced by a respected and experienced developer. Such a developer can best understand the principles behind refactoring and adapt those principles to the specific workplace. This is particularly true when you are using a language other than Java, because you have to adapt the examples I've given to other languages.
Here's how to get the most from this book without reading all of it.
If you want to understand what refactoring is, read Chapter 1; the example should make the process clear.
If you want to understand why you should refactor, read the first two chapters. They will tell you what refactoring is and why you should do it.
If you want to find where you should refactor, read Chapter 3. It tells you the signs that suggest the need for refactoring.
If you want to actually do refactoring, read the first four chapters completely. Then skip-read the catalog. Read enough of the catalog to know roughly what is in there. You don't have to understand all the details. When you actually need to carry out a refactoring, read the refactoring in detail and use it to help you. The catalog is a reference section, so you probably won't want to read it in on.
|
|
| View all 17 comments |
An Australian reader (MSL quote), Australia
<2007-01-10 00:00>
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.
|
Rivera (MSL quote), USA
<2007-01-10 00:00>
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". |
Warren Serota (MSL quote), USA
<2007-01-10 00:00>
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. |
Scott Brookhart (MSL quote), USA
<2007-01-10 00:00>
There are a few books that a software engineer should own or at least have read and this is one of those. Martin Fowler (...) is ahead of his time usually and brings out some very informative, helpful experience to working with code. Working with legacy code, developing new code and realizing it must change are times when a good book like this will be saver. Not only does this book provide some specific how-to, but it establishes guidelines on refactoring and identifies areas where refactoring is probable. |
View all 17 comments |
|
|
