Preface

THE ART OF PREFACTORING APPLIES TO NEW PROJECTS THE INSIGHTS INTO DEVELOPING SOFTWARE YOU HAVE GLEANED FROM YOUR EXPERIENCE , as well as the experience of others, in developing software to new projects. The name of this book plays upon the term refactoring , popularized in Martin Fowler's book, Refactoring: Improving the Design of Existing Code (Addison-Wesley Professional, 1999). Refactoring is the practice of altering code to improve its internal structure without changing its external behavior.

This book delineates prefactoring guidelines in design, code, and testing. Applying the guidelines in this book does not guarantee that you will never need to refactor your design or code. However, you might decrease the amount of refactoring that is required.

Many of these guidelines are derived from the experiences of numerous developers over several years . Analyzing how code might have been initially developed to alleviate the need for refactoring produced other guidelines. Like Extreme Programming, some of the guidelines might seem extreme. Many revolve around the concepts of Extreme Abstraction, Extreme Separation of Concerns, and Extreme Readability.

Some guidelines contain references to design patterns . Design patterns are standard solutions to common problems in software design. The concept of software design patterns was popularized in Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley Professional, 1995). That book discusses patterns of objects and classes that form the basis for the solutions to many common problems. ^[*]

^[*] See Head First Design Patterns by Elisabeth Freeman, Eric Freeman, Bert Bates, and Kathy Sierra (O'Reilly, 2004) for another look at patterns.

A few of the guidelines actually might be called design patterns in pattern circles. According to Design Patterns , "Some people's patterns are another's design principle." In this book, I call them guidelines, because they include concepts that reoccur in numerous situations, not just as design patterns. These guidelines have not been put into a pattern format, since they are just suggested practices to follow when developing a program.

During my 35-year career, I have worked with computer languages ranging from IBM 360 assembler to C, C++, Java?, C#, HTML, and XML. I have also worked with frameworks including J2EE, Struts, and MFC. Along the way, I have had the opportunity to meet and interact with hundreds of developers. These developers have provided me with experiences related to many of the guidelines I discuss in this book.

During that same time, I have had the opportunity to learn from numerous well-known practitioners in the software development field. This book coalesces many of the themes they discussed in their writings, talks, and conversations with the practices I developed during my career. These people include Scott Ambler, Chuck Allison, James Bach, Kent Beck, Grady Booch, Alister Cockburn, Larry Constantine, Jim Coplien, Ward Cunningham, Gary Evans, Bruce Eckel, Martin Fowler, James Grenning, Payson Hall, Allen Holub, Andy Hunt, Jason Hunter, Eric Jackson, Ivar Jacobsen, Ron Jeffries, Cem Kaner, Joshua Kerievsky, Robert Martin, Bret Pettichord, P. J. Plauger, James Rumbaugh, Dan Saks, Jim Short, Joel Spolsky, Bjarne Stroustrup, Dave Thomas, Bill Venner, Gerry Weinberg, Karl Wiegers, and Rebecca Wirfs-Brock.

I have attempted to attribute the original proponent of each guideline I cover in the book; however, the source of many of the guidelines is unclear. If you know who originated any of the unattributed guidelines, please let me know. Some of them are listed in the book 201 Principles of Software Development by Alan M. Davis (McGraw-Hill, 1995), in the book Code Complete, Second Edition by Steve McConnell (Microsoft Press, 2004), and on the Web at http://c2.com/cgi/wiki.

Enumerating guidelines without a context for them is like talking about curling without referring to hair or ice. Therefore, in this book, I present the guidelines in the context of the development of a CD rental system. To my knowledge, such a store does not exist. The video store example in Martin Fowler's refactoring book inspired this choice.

I love outdoor recreation. In particular, I enjoy windsurfing, backpacking, snowboarding, and biking. Bitter Java by Bruce A. Tate (Manning, 2002) gave me the idea to use sports analogies when describing programming. Scattered throughout the book are a few outdoor stories relevant to the topic under discussion.