BUY THIS BOOK
Add to Cart

Print Book $29.95

Add to Cart

Print+PDF $38.94

Add to Cart

PDF $23.99

Safari Books Online

What is this?

Add to UK Cart

Print Book £20.95

What is this?

Looking to Reprint or License this content?

Prefactoring

By Ken Pugh
September 2005
Pages: 238
Series: Theory In Practice
ISBN 10: 0-596-00874-0 | ISBN 13: 9780596008741
starstarstarstarstar (Average of 1 Customer Reviews)

Buy 2 Get 1 Free Free ShippingGuarantee

Book description

Prefactoring approaches software development of new systems using lessons learned from many developers over the years. It is a compendium of ideas gained from retrospectives on what went right and what went wrong in development. Some of these ideas came from experience in refactoring. This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing. These guidelines can help you create more readable and maintainable code in your next project.
Full Description

Prefactoring approaches software development of new systems using lessons learned from many developers over the years. It is a compendium of ideas gained from retrospectives on what went right and what went wrong in development. Some of these ideas came from experience in refactoring. Refactoring is improving the design of existing code to make it simpler and easier to maintain.

This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing. These guidelines can help you create more readable and maintainable code in your next project.

To help communicate the many facets of this approach, Prefactoring follows the development of a software system for a fictitious client, named Sam, from vision through implementation. Some of the guidelines you'll encounter along the way include:

  • When You're Abstract, Be Abstract All the Way
  • Splitters Can Be Lumped Easier Than Lumpers Can Be Split
  • Do a Little Job Well and You May Be Called Upon Often
  • Plan Globally, Develop Locally
  • Communicate with Your Code
  • The Easiest Code to Debug Is That Which is Not Written
  • Use the Client's Language
  • Don't Let the Cold Air In
  • Never Be Silent
  • Don't Speed Until You Know Where You Are Going

Browse within this book

Cover | Table of Contents | Colophon




Featured customer reviews

Write a Review


It's ok but there's better,  December 30 2006
Rating: StarStarStarStarStar
Submitted by Giles Bowkett   [Respond | View]

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

Read all reviews


Media reviews
"The autor of this book has a vast experience of developing computer systems and in this book he shares with you many different ideas that make developing and (particularly) redeveloping computer systems much easier. A very useful guide for those working in program development who don't yet have enough experience to have worked out all of these shortcuts for themselves."
-- Stephen Chapman, About.com


"Having a worked example gives the book a narrative that drives it along, and there are plenty of side-bars, rules, practices and other information to make it more than just a piece of source code fiction. Additionally the final two chapters each provide another worked example, a print server and some anti-spam software respectively. For those that learn most from looking at code these final chapters recapitulate the contents of the rest of the book. This isn't a particularly long book, and it would have been shorter without the narrative, but it's an easy read. The core lessons, which are to do with improving the design of software, are certainly worth learning."
-- Pan Pantziarka, TechBookReport.com

"Prefactoring is all about making guidelines or outlines of what we’ve learned from our programming experiences. These guidelines will aid us in doing only minimal refactoring for our future programs or projects, providing us flexibility in program handling. Technically, this book has taught me lot of things about making a unique program structure that is capable of being reconstructed easily if changes will be required…Prefactoring is a skill that we all must learn now, and I encourage everyone to try out the book."
--Jason Cheng, DigitalFilipino.com, February 2006

"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..."
--Thomas "Duffbert" Duff, Duffbert's Random Musings, October 2005


Read all reviews

See larger cover


"A very useful guide for those working in program development who don't yet have enough experience to have worked out all of these shortcuts for themselves."
--Stephen Chapman, About.com