Customer Reviews

Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability

5 star:		(5)
4 star:		(7)
3 star:		(5)
2 star:		(2)
1 star:		(1)

 

 

That's "Design Lite." There's a lot of good advice here, summarized in the aphorisms of appendix A. That includes the usual about avoiding "magic numbers," and some good points about using inclusive data types (strings, for example) to hold values with many incompatible meanings. Pugh also noted that "function codes" as method parameters generally cause problems. If there are different functions to perform, implement them as different methods - don't make one method do lots of different jobs according to some selection key. He could have noted, however, that the "function code" is often a bad smell indicating polymorphic behavior that should have been implemented with class polymorphism.

The presentation as a whole just didn't work for me, though. There were lots of little things, like a sloppy misquote of Santayana's famous "Those who cannot remember the past are condemned to repeat it," minor but annoying. The whole conversational, I-said-then-he-said style is too user-friendly for me - by the time the writer finishes piling on all the scripting flourishes, discussion tends to evaporate into fluff. Pugh could have just made his point without chopping it into pieces and mixing in fictional personalities. Much of the good in this discussion was buried under this chatty style, or lost amid the scene-setting details preparatory to the real discussion of planning for extensibility.

The technical problems were the big ones, though. In discussing error handling (p.35), he omits mention of the worst sin I know: silently converting a bad value into something you'd rather deal with. He also missed the biggest extensibility problems I've seen in any system, the ones where external data formats change over time. That happens when your 2.0 program reads a file written by the 1.0 version, and the file format has changed. It can also happen when someone creates a version 2.0 file and sends it to a user still running version 1.0. It happens in worse form when your networked application requires that 2.0 and 1.0 versions of the code talk to each other. Face it, you'll never be able to take down the whole production network and force all the servers to run the same rev of protocol. Inter-version interoperability is a must in any major application, and simply not mentioned here.

There is good in this book, but it is often hidden under poor organization, weak descriptions, and lack of technical explanation. Beginners may get a bit from this book but, on the whole, I don't recommend it.

//wiredweird

I think the title is misleading, the book is little, if any, related to Martin Fowler's seminal work on refactoring, instead, the book is mostly a collection of best practices, much more like "Code Complete" by Steve McConnell. Nothing revolutionary or innovative, but the book reads quite well and provides a nice good walkthrough of a fictional project. Beginners may benefit a lot from this; more seasoned developers may use it as reminder for best practices.

This book does what it sets out to do: it describes some wise ideas for software design. (If the name of the book bothers you, get a grip: at least it's short.) Some of these ideas may be familiar to experienced developers, in which case it's a well-written refresher. For some of the ideas, this may be the first time you've seen them described in that way, and a different perspective is also useful.

So, what do I like about this book?

- The ideas are practical, common-sense ones.

- I like the revisiting of a small number of examples, developing them a little more each time as familiar problems with them are identified.

- The book sits comfortably in the world of Agile development, but is not rabid about it.

- Design diagrams are used sparingly, enough to educate and remind, but not overwhelmingly so.

Prefactoring is an exposition of principles for software design, laid out in the context of the development of a fictional application. I've never been into that particular style of writing about software design; in fact, it was the only thing I didn't like about Martin Fowler's Refactoring, which is the inspiration for both Prefactoring's own fictional case study and its name as well.

When you've got one programming book named after another one, one reasonable idea is to compare the two. Prefactoring's premise is that, instead of fixing your design afterwards -- an extremely terse summary of Refactoring -- you apply what you've learned from that in the past to build it with the right design principles from the get-go. That sounds like good common sense, and it is. Unfortunately, it really only makes sense in the context of a misunderstanding of Refactoring. Refactoring and debugging are different things. It's very common in software for people to use buzzwords and catchphrases as an alternative to thinking, and consequently, in certain organizations, you'll hear "refactoring" used as a synonym for "debugging."

In fact, refactoring is supposed to happen during debugging -- but it's also supposed to happen during the course of development, and in fact this is the preferred time to do it. Refactoring comes from agile development, specifically Extreme Programming, where the basic cycle is to write unit tests, write the simplest code that can possibly satisfy those tests, refactor that code, and then begin again with new unit tests. Refactoring can mean improving things during debugging, but much more importantly, what it really means is streamlining existing code as you refine it. To say that the best thing to learn from refactoring is to get your code right first time is to use the vocabulary of agile development to advocate waterfall development, and this, in fact, is what Prefactoring often seems to do.

Worse still, many of the code examples are in Java, and they don't use Josh Bloch's guidelines from Effective Java or Java Puzzlers. This might be a quibble, but I'd certainly hire or fire based on this quibble, as I think it's very important (and therefore not a quibble at all). Pretty much everything I've done for months has been in Ruby on Rails, so I'm frequently reminded that Java is not popular in every sector of the tech industry -- however, if you are going to write Java, I personally feel that writing Java without observing Bloch's guidelines is careless at best, and borders on outright negligence.

On the other hand, I seem to be kind of eviscerating this book here, and that's not quite fair. I disagree with some of the design principles laid out in this book, but most of them are pretty strong in the common sense department. Also, software development is one of those things where you can be better off after reading a book even if you disagree with it. For instance, just in criticizing this book's attitude towards refactoring, I've had to question my own understanding of it. If you read this book with the right frame of mind, you'll challenge your own ideas and come to new conclusions, and probably become a better developer in the process.

While prefactoring is a cute name, refactoring refers to continuous improvement of code, facilitated by unit tests, not stopping a project to do a redesign. The fundamental principle is producing code that is easy to change, because attempting to get it right the first time often prevents getting it right at all.

I was attracted to this book by the title: 'refactoring' and the agile development philosophy are sometimes used as an excuse for insufficent design. So I liked the explicit emphasis on the need to get stuff right the first time.

Ken Pugh writes with an engaging style that is very easy to read and makes sound suggestions. It would be a valuable guide for new developers looking to broaden their horizons from tools and code. However, there is not a lot that is new in this book and the principles are somewhat introductory for a more experienced programmer. 'Journeymen' programmers would be better served by the Practice of Programming by Kernighan and Pike, or by the Pragmatic Programmet by Hunt and Thomas.

Prefactoring - Extreme Abstraction, Extreme Separation, Extreme Readability by Ken Pugh involves a twist on the concept of "refactoring", improving the design of a program (or module) after the fact while retaining the same functionality. Prefactoring is making sure good design techniques are practiced up front to help avoid having to refactor as much later...

Contents: Introduction To Prefactoring; The System In So Many Words; General Development Issues; Getting The Big Picture; Got Class?; A Few Words On Classes; Getting There; The First Release; Associations And States; Interfaces And Adaption; Zip Codes and Interfaces; More Reports; Invoices, Credit Cards, And Discounts; Sam Is Expanding; A Printserver Example; Antispam Example; Epilogue; Guidelines And Principles; Source Code; Index

Pugh runs an imaginary development project (Sam's CD Rental and Lawn Mower Repair) where a new system is built to allow customers to rent CDs. This is currently a manual process, but the owner wants to automate it. By using prefactoring design techniques throughout, the developers are able to build the system such that it's much easier to make changes and design modifications later on without causing major rework. Throughout the book, each step in the process is recapped in a short maxim that makes the concept easy to remember and apply to your own situation. For instance, "Do A Little Job Well And You May Be Called Upon Often - Methods and classes that perform specific jobs can be reused more often" and "Figure Out How To Migrate Before You Migrate - Considering the migration path might help you discover additional consideration in other areas of the design". Personally, it's these little gems that make the book most valuable.

I can see how some people would think this "prefactoring" is nothing more than good design techniques. That's probably a valid point. I don't know that prefactoring is some new revolutionary approach to design that will rank up there with things like agile methodologies and such. But it does allow you to wrap your mind around a general concept ("good design") and develop a framework for improving your skills in that area. For that, it's a valuable read...

This book is a bit difficult for me to review. It follows the tried and true O'Reilly template of giving decent but shallow overview that is enough to get you going, but not really all the details you will need. Pugh gives a nice overview of many useful concepts for improving ones software design, but the coverage is very light. For a bookworm like myself who has read Code Complete, The Mythical Man Month, Exceptional C++ Style, and a half dozen other titles on the same lines, I think I was just beyond the working level of the presination in Prefactoring. If you are the sort of developer who has made a fairly serious study of techniques for improving code design and implementation, there isn't much new that you are going to see here.

On the other hand, Prefactoring may very well be a good starting point for a novice developer. It is an easy read and it does introduce many useful concepts with at least one simple application of each. Unlike Code Complete, Prefactoring can easily be read in a weekend and does't make a huge demand on the readers time. It has plenty of good references that the beginner can use to really dig deep into the topics presented, so you will know where to go next to really understand and apply the ideas introduced here. I can also say that I think the example CD sales system was used pretty well. It had enough complexity to at least offer non-trivial examples, and the evolution did reasonably follow the lifecycle of a real software product (though don't expect any project you are working on to be this easy).

In the end, I have a bit of a difficult time rating this book. I tend to score it down for not offering me anything new that I didn't know before or learn for more complete references. On the other hand, I probably wasn't really the intended market for this book to begin with. Not being a novice any longer, it is hard to know if I would have found this book all that useful, but I suspect I would. This inclines me to raise my assessment some. I'd go with 3 1/2 stars if I could, but settled on 3 for being a bit dissapointed.

As a postscript, for those who have criticized this book for misrepresenting refactoring, I'd say they are correct, but I don't think that's much of a criticism. I think its clear from the exerpted material and blurb that this is really a general book about improving your code. It should be fairly obvious that the Prefactoring title is a bit of a marketing ploy to hitch a ride on an industry buzzword, but I don't begrudge the author trying to sell a few books. It's clear what he's really offering.

This is a nice book on the basics of object-oriented design. It will also tell you that you need to write tests, document your code, log errors, follow naming conventions etc. The issue I have with this book is that it claims to be addressed at those who "understand object-oriented design" and are looking for "more efficient designs", but unless you have never before participated in a real world software development project or done any object-oriented design you are unlikely to learn much.

The problem with this book is more fundamental than a misleading title or a missed analogy with Martin Fowler's Refactoring book. The author completely misunderstands and misrepresents the practice of refactoring. Developers do not "stop" to refactor because their original design was wrong; quite the contrary, refactoring is an integral and ongoing part of Agile development. There is no "stopping" and the act of refactoring does not extend the development timeline. "Prefactoring" is nothing more than traditional, up-front design. The author attempts to co-opt terms that have a specific meaning, much like Humpty Dumpty in Through the Looking-Glass, when he tells Alice, "When I use a word, it means just what I choose it to mean, neither more nor less."

The book is worse than useless; if it were merely useless, it would convey no information. Instead, it actually misleads readers with inaccurate information. Consider the comments of reviewer ueberhund, who writes refactoring "is the act of re-writing and re-working code until it reaches a state of perfection. Since perfection is never achieved, the work of refactoring goes on for ever." Also note the comments of reviewer Thomas Duff, who writes, "Prefactoring is making sure good design techniques are practiced up front to help avoid having to refactor as much later." These comments illustrate that many software professionals thoroughly misunderstand the basic concepts of adaptive or Agile development. A book like this one exacerbates that problem.

The software industry is currently in a time of change, when adaptive methods are being more widely adopted and integrated with the best practices of information technology organizations. It is the worst possible time for misinformation like this, because it muddies the waters just when people need to understand accurately the risks and potential value of various approaches to software development.