Prefactoring

Extreme Abstraction - Extreme Separation - Extreme Readability

Summary

Developers often rethink and recode software 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 what you can do to reduce the amount of refactoring. 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.

To help communicate the many facets of this process, Prefactoring follows the development of a software system 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 these 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.

Order on Amazon

Articles

What Is Prefactoring on oreilly.net

Reviews

Stephen Chapman

Duffberts's Random Musings

Keith Ray - read carefully