Refactoring: Improving the Design of Existing Code
||Author: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts|
List Price: $54.99
Our Price: Click to see the latest and low price
Publisher: Addison-Wesley Pub Co (28 June, 1999)
Sales Rank: 3,069
Average Customer Rating: 4.58 out of 5
Customer ReviewsRating: 5 out of 5
Great book on a variety of levels.
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.
Rating: 5 out of 5
Great reference for when and how to change existing code
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."
Rating: 5 out of 5
Masterly, Comprehensive Reference on Refactoring
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."
· Agile Software Development, Principles, Patterns, and Practices
· Extreme Programming Explained: Embrace Change
· Test Driven Development: By Example
· Design Patterns
· Patterns of Enterprise Application Architecture