Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability

by Ken Pugh

Developers working on a project will often rethink and recode the software under construction to make its design cleaner and more elegant. Known as "refactoring," this process is done for all sorts of reasons: to facilitate the addition of new features, to improve maintainability, and (or) to increase performance. Refactoring is an important and useful software process.

Refactor enough times though, and you will begin to learn things that you can do when building new software to reduce the amount of refactoring later in the process. Taking these lessons-learned and applying them on subsequent development projects is a process that Ken Pugh refers to as "prefactoring".

This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing, each derived from the lessons of many developers over the years. By following these guidelines, you're far more likely to create more readable and maintainable code than would otherwise be the case.

To help communicate the many facets of this process, Prefactoring follows the development of a software system for a fictitious client, named Sam, from vision to 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

If you have an object-oriented design background, you may save time by considering Ken's prefactoring guidelines before you begin your project, They won't guarantee that you will never need to refactor your design or code again, but you can cut down on the amount of refactoring you do.

Genres: Programming, Coding, Nonfiction, Technical

Paperback

First published September 1, 2005

About the author

A principal consultant with Pugh-Killeen Associates since 1982). His professional interests are development processes (especially agile ones), object-oriented design, and security. He has been involved with projects ranging from satellite tracking to goat serum process control to stock portfolio analysis. He's ambidexterous - developing for both Windows and UNIX/Linux.

Reviews

[Alfredo Chavez · Rating 3 out of 5]

Lots of solid and thought-provoking advice. It encourages to build software based on lessons learned (by ones self and by others) instead of reinventing the wheel again and again... and fixing that wheel when you find you didn't get it right

[Loren Runcie · Rating 5 out of 5]

boring!

[Ronald · Rating 4 out of 5]

Good stuff to think about. I like his views on errors and exceptions. I've been struggling with that for years and have decided to adopt his model.