|
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 |
|
|
Joshua Davies (MSL quote), USA
<2007-01-10 00:00>
Although this book has been around for a few years now, the technique that Fowler names "Refactoring" is as old as programming. I've been doing refactoring for the twelve years I've been a professional programmer, often to the chagrin of my supervisors; they often seemed to subscribe to the "if it ain't broke, don't fix it" mentality. Yet I could always tell that the code *was* broken, even if it didn't appear that way when the product was used. I was beginning to suspect that I was the only one who saw this, and then I read this book - written by an eminent researcher in the field and one of the brightest people to ever put pen to paper.
By giving a name to the technique, it can be talked about in planning/ design meetings, discussed as a best practice, measured, and demon- strated. But Fowler takes it much further - he gives names to common refactoring techniques as well as what he calls "bad smells", or signs that you need to refactor. ("Speculative generality", for example - a perfect name for an annoying tendency of the 10,000-foot architects).
This book is well-researched and well thought out, and is a must-read for anybody who's serious about software development. It's principal value is in providing common terminology for common actions, in addition to good justifications for each refactoring. |
|
|
Kan Xinbo (MSL quote), USA
<2007-01-10 00:00>
While it is no groundsbreaking stuff, it is very useful for people who want to bring better design into existing code; or those who are just unhappy with the existing code. It clearly identified common problems with existing code and provides techniques to help you make it better. While experienced programmers have most likely used some of these techniques on their own, reading this book helps you remember/organize these techniques in your mind. One of the most useful things is that Martin outlines the steps to take to get to the desired code - each step is very small so as to minimize your chance of screwing it up. |
|
|
R. Stokes (MSL quote), USA
<2007-01-10 00:00>
Some of the reviews here have focused on this book as a way of learning coding techniques for refactoring. Other reviews have focused on refactoring being another term for what they have already being doing. While learning some new coding techniques might be a side effect of reading this book, the real value of this book is descibing a process and terminology for facilitating refactoring - something that many developers have done on an ad-hoc basis for years. It has been invaluable in broadening the acceptability of refactoring, an activity that was often dismissed as not being a good use of development resources time. It also gives a vocabulary for discussing refactoring rather than relying on engineers own adhoc practices. And there's probably a few refactoring techniques that won't seem obvious.
For C# users, you may wish to look at NUnit.org for a .Net version of the JUnit software mentioned in the book. |
|
|
A. Johnson (MSL quote), USA
<2007-01-10 00:00>
I like the way this book is arranged. There are several short sections that define refactoring and when to apply it. This portion of the book contains references to the later sections which are the refactoring methods. By arranging the book in this manner, the author provides the reader with a quick understanding of the technique, then allows the reader to grasp the specifics on an as-needed basis. It's a refreshing approach to software books, and something I would like to see more often. |
|
|
Lars Bergstrom (MSL quote), USA
<2007-01-10 00:00>
Great advice on when, how, and where to refactor. It also surprised me by having a bit more relevant stuff for big projects than the usual software principles and practices books do - I'm used to having to extrapolate for myself. In addition to the great text, there's also a wonderful encyclopedic list of transforms. They're understandable enough to read and perform as a human, but also semantically well-defined enough to make tools almost directly on top of.
The last few chapters unfortunately felt 'stapled' onto the end. They all had a very different feel from the rest of the book and, while they were interesting viewpoints, they made it lack some consistency. It would've been good to have either Fowler-ized them or just left 'em out. I'm not clear how much value they added, other than saying, "Tools are good to do refactorings. Without them, people aren't too religious about it. But don't trust the tools too much; baby-steps and test verifiction is still crucial." |
|
|
An American reader (MSL quote), USA
<2007-01-10 00:00>
Do not be fooled by the title: This book works just as well as a style guide for class design in new development as it does for rewriting existing code. The writing is easy to understand, and the examples are kept simple for clarity. It works well both as a reference and as a cover-to-cover read. The book also helped illuminate many design patterns. The only downside: After reading this book it was almost painful to go back and "smell" my own code. But I immediately set about refactoring, with tremendous results. This book is a "must-have." |
|
|
Ray Ye (MSL quote), USA
<2007-01-10 00:00>
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. |
|
|
|
1 2 Total 2 pages 17 items |
|
|
|
|
|
|
