C#敏捷开发实践

        本书英文书名中首先提到的一个关键术语是自适应代码（Adaptive Code），这一关键术语很好地诠释了应用本书中介绍的基本原则能够达成的效果：无需大量返工，代码即可自动适应后续新的需求和无法预见的场景。本书旨在将使用 Microsoft .NET Framework 进行 C#编程的当前最佳实践囊括于一卷之中。尽管其他书中也会涵盖本书中的某些内容，但这些书要么偏重于讲解理论，要么就不是特定于.NET Framework 开发的。编写代码不能急于求成。与阻碍变化的代码库相比，如果你的代码具有自适应能力，你就能够更加快速、轻松地对其进行更改，并且不会引发多少错误。相信大家都知道，对于需求，不变的主题就是变化。因此管理需求变更是软件项目成败的一个关键因素。面对需求变更，开发人员可以有很多种应对方法，这些方法可以归类到下面要讲述的两种方法论。这两种方法论的主旨几乎是截然相反的，特别是在变更处理的连续性上。第一种是瀑布方法论。这种方法论要求开发人员必须遵循严格的流程。应用这种方法论的项目中，大到要遵循的开发流程，小到要实现的类型设计都很不灵活，甚至几乎与 50 年前用穿孔卡片进行编程开发一样死板。所有瀑布方法论都在竭尽全力确保软件很难被自由更改。软件开发被划分为分析、设计、实现和测试几个显著不同的阶段，而且整个过程是单向的。一旦进入实现阶段，用户就很难去变更需求，或者说至少要付出昂贵的代价才能变更需求。当然，代码也无需为需求变更作任何准备，因为整个瀑布流程几乎不提供任何其他选项。第二种是敏捷方法论。它不仅仅是另一种选择，而且是对瀑布方法论的一种彻底推翻。敏捷流程的主旨就是拥抱变化，它被看作是客户和开发者之间的一个必要的联系纽带。如果客户想要对自己付费的产品进行某些改变，就应该把时间和资金的代价与需求的变更关联起来，而不是直接把变更加入流程中正在进行的阶段。软件工程的基础是源代码，相对于物理工程，它具有更好的可塑性。建造一座房子的过程就是使用水泥把砖逐块粘合在一起，所以改变房子设计的代价就很自然地与房子的建造完成度直接相关了。假设工程尚未开始，只有设计蓝图，那么变更设计的代价相对来说就会很低。如果已经装好了窗户，布好了电线、管线，此时再想把楼上的浴室改到楼下的厨房旁，那代价就会非常高了。软件产品的源代码具有良好的可塑性，因此移动特性和修改用户界面的导航看起来不应该有很高的代价，但不幸的是，事实并不总是如此。单单时间成本就经常不允许在软件产品中进行这样自由的变更。在我看来，这主要就是因为代码缺乏对需求变更的自适应能力。本书将通过一些实际的例子，为大家演示和讲解敏捷流程以及如何编写自适应代码。

百度网盘地址：https://pan.baidu.com/s/17GnkCh3pvNVNhYUGKDJjCg

解压码：e03a

封面图片