xv
Introduction
The title of this book, Adaptive Code, is a good description of the outcome of applying
the principles in the book: the ability of code to adapt to any new requirement or un-
foreseen scenario while avoiding signicant rework. The aim of this book is to aggregate
into one volume many of the current best practices in the world of C# programming with
the Microsoft .NET Framework. Although some of the content is covered in other books,
those books either focus heavily on theory or are not specic to .NET development.
Programming can be a slow process. If your code is adaptive, you will be able to make
changes to it more quickly, more easily, and with fewer errors than you would if you were
working with a codebase that impedes changes. Requirements, as every developer knows,
are subject to change. How change is managed is a key differentiating factor between
successful software projects and those that fail. Developers can react in many ways to
requirement changes, with two opposing viewpoints highlighting the continuum that lies
between.
First, developers can be rigid. In this approach, from the development process down
to class design, the project is as inexible as if it were implemented 50 years ago by using
punch cards. Waterfall methodologies are conspicuous culprits in ensuring that software
cannot change freely. Their determination that the phases of analysis, design, implemen-
tation, and testing are distinct and one-way make it difcult—or at least expensive—for
customers to change requirements after implementation has begun. The code, then, does
not need to be built for change: the process all but forbids alterations.
Second, developers can be adaptive. Agile processes are not just an alternative to
such rigid methodologies, but a reaction to them. Their aim is to embrace change as
a necessary part of the contract between client and developer. If customers want to
change something in the product that they are paying for, the temporal and nancial
cost should be correlated to the size of the change, not the phase of the process that is
currently in progress. Unlike physical engineering, software engineering works with a
malleable tool: source code. The bricks and mortar that form a house are literally fused
together as construction progresses. The expense involved in changing the design of
a house is necessarily linked to the completion of the building phase. If the project
has not been started —if it is still just in blueprints— change is relatively cheap. If the
windows are in, the electricity wired up, and plumbing tted, moving the upstairs
bathroom down next to the kitchen could be prohibitively expensive. With code, moving
features around and reworking the navigation of a user interface should not be so signi-
cant. Unfortunately, this is not always the case. The temporal cost alone often prohibits
such changes. This is largely a result of a lack of adaptability in code.
剩余448页未读，继续阅读
