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
Chapter One Introduction to Prefactoring
What Is Prefactoring?
The Three Extremes
The Guidelines Explored
The Context for This Book
Chapter Two The System in So Many Words
Meet Sam
Reinvention Avoidance
What's in a Name?
Splitters Versus Lumpers
Clumping
Abstracting
Prototypes Are Worth a Thousand Words
Chapter Three General Development Issues
Start with the Big Picture
Interface Contracts
Validation
Code Communicates
Consistency Is Simplicity
A Prefactoring Attitude
Don't Repeat Yourself
Documentation of Assumptions and Decisions
Dealing with Deviations and Errors
Speeding
The Spreadsheet Conundrum
Tools Are Tools—Use Them Wisely
Chapter Four Getting the Big Picture
The Rest of the Story
Process
The Initial Design
Global Planning, Local Designing
Testing Functionality
Testing Quality
Security
Chapter Five Got Class?
Categories and Classes
Declaration Versus Execution
Appropriate Inheritance
Communicate with Text
More Than One
Chapter Six A Few Words on Classes
Honor the Class Maxims
Three Laws of Objects
Need Determines Class
Polymorphism
One Little Job
Policy Versus Implementation
Extreme Naming
Overloading Functions
Chapter Seven Getting There
Where We Are
Separating Concerns
Migrating to the New System
Chapter Eight The First Release
The Proof Is in the Pudding
Retrospective Time
The System as It Stands Now
Operations Interface
Abstract Data Types
Configuration
Testing
Dealing with Deviations and Errors
A Little Prefactoring
The First Released Iteration
Sometimes Practice Does Not Match Theory
The Rest of the Classes
Chapter Nine Associations and States
Sam's New Requirement
Who's in Charge?
The State of an Object
Chapter Ten Interfaces and Adaptation
The Catalog Search Use Case
Designing the Interface
Interface Development
Interface Testing
Interface Splitting
Something Working
Chapter Eleven Zip Codes and Interfaces
Adaptation
Pass the Buck
Unwritten Code
Indirection
Logging
Paradigm Mismatch
Chapter Twelve More Reports
Fancy Reports
Change Happens
Exports
Chapter Thirteen Invoices, Credit Cards, and Discounts
Ken Pugh has extensive experience in the area of software analysis and design, both as a doer and as a teacher. He's a well-known, frequent conference speaker.
About the authorKen Pugh has extensive experience in the area of software analysis and design. He has worked on systems ranging from goat serum process control to financial analysis to noise recording to satellite tracking. His previous books were on C and Unix, and he is a former columnist for the C/C++ Users Journal. He has taught programming courses for Wellesley College and the University of Hawaii, as well as numerous corporate courses, and he frequently presents at national conferences. As an independent consultant for over 20 years, he has served clients from London to Sydney. As an expert witness, he has provided testimony in both civil suits and criminal cases.When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail.
ColophonOur look is the result of reader comments, our own experimentation, and feedback from distribution channels. Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects.Sarah Sherman was the production editor and proofreader, and Audrey Doyle was the copyeditor for Prefactoring . Mary Anne Weeks Mayo and Claire Cloutier provided quality control. Lydia Onofrei provided production assistance. Johnna VanHoose Dinse wrote the index.MendeDesign designed and created the cover artwork of this book. Karen Montgomeryproduced the cover layout with Adobe InDesign CS using the Akzidenz Grotesk and Orator fonts.Marcia Friedman designed the interior layout. Melanie Wang designed the template; Phyllis McKee adapted the template. The book was converted by Keith Fahlgren to FrameMaker 5.5.6 with a format conversion tool created by Erik Ray, Jason McIntosh, Neil Walls, and Mike Sierra that uses Perl and XML technologies. The text font is Adobe's Meridien; the heading font is ITC Bailey. The illustrations that appear in the book were produced by Robert Romano, Jessamyn Read, and Lesley Borash using Macromedia FreeHand MX and Adobe Photoshop CS.
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
