|
Refactoring: Improving the Design of Existing Code (精装)
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. |
|
| |
AllReviews |
1 2   | Total 2 pages 17 items |
|
|
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. |
|
|
Billy (MSL quote), USA
<2007-01-10 00:00>
After a year of OOP with C#, I finally feel that I'm writing some well written code with the help of Martin Fowler's Refactoring. Fowler defines a number of "smells" indicating areas of your code that may need refactoring. He then offers clear and concise methods for clearing the smells; resulting in more extensible and understandable code. This book is great for learning refactoring and as a quick reference...it should be found on every OOP developer's bookshelf. |
|
|
Dave (MSL quote), USA
<2007-01-10 00:00>
A reasonable amount of the refactorings listed are helpful and I learned good things from reading about them. However, too many of them are basic programming heuristics that many of us know already. I would have liked the authors to spend more time on OO design centric refactorings or at least more advanced general programming refactorings. This book would be helpful to the beginner, but more experienced programmers probably already do many of these refactorings on their own. |
|
|
Galiano (MSL quote), Spain
<2007-01-10 00:00>
Refactoring is no more than restructuring code by altering its internal structure without changing its external behavior. At first sight, it could seem that such innocuous transformations (from an external point of view) would not deserve a whole book. However, refactoring is one of the key techniques behind the success of agile software development.
Among other things, refactoring makes supple designs and test-driven development possible. When properly used, it helps in software maintenance (see Michael Feathers' Working Effectively with Legacy Code). It also provides tangible benefits in debugging: if you don't find the error, that's because you don't understand what the code does, so making it clearer will always help.
Although you might find Fowler's catalog of refactorings rather dry and many integrated development environments automate them nowadays, thus making Fowler's recipes unnecessary, it is fair to recognize the milestone this book marked when it was first published a few years ago. |
|
|
Vladimir Levin (MSL quote), USA
<2007-01-10 00:00>
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. |
|
|
Robert Gamble (MSL quote), USA
<2007-01-10 00:00>
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.
|
|
|
David Veeneman (MSL quote), USA
<2007-01-10 00:00>
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. |
|
|
|
1 2 | Total 2 pages 17 items |
|
|
|
|
|
|
