章节 1.3 极限编程 – 灵活，可靠的软件 使用设计模式和敏捷开发

首先一个敏捷方法是极限编程，或者简写为XP。在千禧年之初得到了很多的关注。XP倡导的许多核心方法在本书中都有所展示且是很好的敏捷方法的代表。

1.3.1质量和范围

在书籍Extreme Programming Explained, Kent Beck (2000)中作者用一个软件开发模型来解释了XP中的一些决议，在这个模型中软件产品是由4个参数所控制的：成本，时间，范围和质量。成本原则上就是产品的价值当然也与分配到此项目上工作的人的数量有很打的关系。时间是在交付期限前总的时间。范围是就所需功能而言项目的大小。质量是关于，比方说，可用性，期望的达成度和可靠性。这4个参数有很复杂的关系，在项目中改动一个将会影响到另外几个，关系不简单，例如你可能可以加入额外的开发人员到项目中来增加成本以加快交付（减少时间），但是把开发人员翻一倍肯定不会使交付时间减半。

公司经常决定前3个参数（成本，时间，范围）而留下第4个参数（质量）作为唯一开发人员可以控制的参数。一个项目典型的开始点是：我们有3个月（固定时间）来完成这份规格书中的需求（固定范围）且这8组个开发人员将被分配到项目（固定成本）。因为时间估算一般都是乐观的，开发人员没有其它选择，只能牺牲质量来满足这个标准：按时交付，所有的功能都有实现，团队规模固定。即使这样，我们软件开发声明仍然不乏大量没有按时交付，没有交付所有的特性和超过预算的例子。

XP关注于使范围这个参数来为团队控制，而不是质量。也就是说，成本，时间和质量这3个参数都是固定的，但范围是留下给团队来做改变的。比方说，假设3个特性需要包含在下一个发布中，但工作开始后发现没有足够的时间来用高质量代码来实现它们，在XP中，客户将会被邀请参与进来，挑选一个到两个最重要的特性加入到发布中，两个可工作的特性比3个有缺陷且没完成的特性要更有价值。

毫无疑问，XP用交换范围和质量两个角色从根本上支撑了很多实践：

• 为了控制和测量质量，引入了自动化测试，加入到了一个称作测试驱动开发的范例中。测试驱动开发将是第5章中学习的核心内容。为了保证代码质量重构也集成到了开发过程中，重构将是第8章中学习的核心内容。
• 为了控制范围，需要一个现场客户，因此交互和决定能很快被作出且能规避信息被曲解。经常性的小的发布确保时间总被投资在最能满足客户需要的特性和方面。

 

1.3.2 价值和时间

XP以4个主要价值为基础

• 交流。一个最基本的治疗失误的方法就是使人们相互交流，XP重视人与人之间交流：开发人员间，开发人员与客户和管理层之间等。
• 简单化。“什么是最简单且能工作的东西？”在XP中你关注于那些将被放在下一个发布中的特性而不是也许6个月后才需要的。
• 反馈。你需要反馈去了解你是否是朝向目标正确的道路上，而且你需要其具有及时性。如果一个你正在开发的特性不能满足客户的需求，你得今天就知道不然后面的6个月工作将不具成效。XP关注于从自动化测试和现场客户那里，分钟或小时级的反馈，从小的发布中得到周或月级的反馈。
• 勇气。抛弃一些代码和对设计做大的更改是需要勇气的，然而一直在坏的设计上开发或在低质量代码中修改缺陷从长远来看是很浪费资源的。

基于这些价值进化出了大量实践。下面我将描述一些对开发和本书上下文很重要的实践。这里需要提醒的是XP包含了其它更多的一些实践但这些关注于开发的其它方面，比方，计划，管理和人员问题，这些都不是本书的核心内容。

XP中一个很主要的技术是结对编程。代码任何时候都将不会仅由个人产生，而是两个人坐在一起用一台电脑开发。每个人有一个特定的角色。操作键盘的那个人在比较仔细的级别关注于实现功能的可能最好方法，而另一个人则更多地从策略上思考和评估设计，审查产品代码，查找简化的可能性，定义新的测试用例且保持进度。结对是动态的，开发人员与不同的人结对且轮换两种不同的角色，要使这个可行，代码集体所有制是很重要的：任何开发人员都可以修改任意代码只要这对团队是有价值的。值得注意的是这个和无所有权制是不一样的，无所有权制开发人员出于自己的意愿来修改代码而不考虑这对团队是否有好处。集体所有制也促使开发人员遵循同样的代码规范，也就是说用一样的缩排方式，一样的类和变量命名规则等。结对编程既是质量又是交流方法，它关注于质量，因为没有写出来的代码没被至少两人阅读或检查且两个人知道代码的含义。它也关注于交流：两人相互传授与学习项目的领域知识和开发技巧，因为是动态结对，知识在整个团队中扩散。

自动化测试对于XP至关重要，在第2和5章中将详述。自动化测试就是被电脑执行的测试而不是人。电脑既不会出错也不会对每10分钟执行同一包中的500个测试而感到乏味，而且执行得很快。经常性地在软件系统上执行自动化测试，系统反馈自身的健壮性和质量，而且开发人员和客户可以测算进度。这些测试应该在任何情况下都通过。为了得到“符合需求”的反馈，你经常性的做一些小的发布：每个月，每两周或甚至于每天。一个小的发布是一个可工作的但功能不全的系统。在项目开始它可能作为与最终用户和客户讨论是否满足目的的介质；然而小的发布将很快被安装到产线且和一直增加的功能一起使用。持续集成意味着各个结对编程的组把开发的东西持续加到项目中以确保开发的代码与其它组的代码没有冲突。集成测试是第8章中的一个重点。

客户和用户需求被捕获成段的关于用户可见功能的故事，这些故事都被写在有序号的卡片且有一个短的标题。如“在特定的时间间隔允许停止录像”，“把列中的数字对齐”，“在电子数据表中加入汇率转换工具”，“利用加起来的所有的存款减去所有的扣除来计算帐号余额”等。最后将他们贴在墙上或其它全部可见的地方，而且每个故事都按开发时间来估算。这样使得开发人员和客户挑选那些最可能提供价值且开销最小的故事。故事应该被规范化，因此它们可以在4～16个小时的结对努力中达到，一旦一组选定一个故事，它将会被进一步分解，在第5章的测试驱动开发中中将会提到。

XP是一个迭代程度很高的开发过程。工作被组织在小的迭代中，每一个都有明确定义的关注点。在最小的程度一个迭代可能持续几分钟去实现类中的简单方法，在下一个程度，可能持续几小时到一天去实现一个特性或特性的前提条件，且最变为把这些特性加入到产品中，下一个程度，小的发布定义一个迭代，持续几周到一个月去实现一套供用户使用的相关的特性。它遵循着也是递增开发流程，系统逐步成长而不是一开始就非常详细地去设计。

XP强烈关注人的交互，意味着它适合于小的或中型程度的团队。有很多人参与的大的项目需要更苛刻来确保适当的信息在正确的时间给了正确的人，这就是说，任何项目都该使用“拆分和攻克”策略，以使有许多小的团队工作于子系统或系统的某些部分，这样这些团队中都可以使用XP或另外的敏捷方法。

 

翻译自书籍：Flexible, Reliable Software Using Patterns and Agile Development, Henrik Baerbak Christensen

后面的翻译将陆续更新…  下一篇，1.4 主要概念总结