"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 WaySplitters Can Be Lumped Easier Than Lumpers Can Be SplitDo a Little Job Well and You May Be Called Upon OftenPlan Globally, Develop LocallyCommunicate with Your CodeThe Easiest Code to Debug Is That Which is Not WrittenUse the Client's LanguageDon't Let the Cold Air InNever Be SilentDon't Speed Until You Know Where You Are Going
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.
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