XP中的重要惯例和规则

1项目开发小组（Team）

在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人
对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项
目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕
最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员，他们帮助
客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、
解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的
交流沟通等等。项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP
鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的XP开发小组。

2计划项目（PlanningGame）、验收测试、小规模发布（SmallReleases）

XP开发小组使用简单的方式进行项目计划和开发跟踪，并以次预测项目进展情况和决定未来的步骤。根
据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过
测试的、可以使用的系统。

•计划项目

XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该
做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始
就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP
中又两个主要的相应过程：

软件发布计划（ReleasePlanning）。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成
本、风险和每个需求的重要性，制订一个大致的项目计划。最初的项目计划没有必要（也没有可能）非
常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程
中被不断地调整以趋精确。

周期开发计划（IterationPlanning）。开发过程中，应该有很多阶段计划（比如每三个星期一个计
划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新
功能，或者会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已
经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在
每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。
这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过
一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。
这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星
期，客户总能够实实在在地看到开发人员已经完成的需求。在XP里，没有什么“快要完成了”、“完成
了90%”的模糊说法，要不是完成了，要不就是没完成。这种做法看起来好象有利有弊：好处是客户可以
马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做
出来的东西，可能会很不满意甚至中止合同。实际上，XP的这种做法是为了及早发现问题、解决问题，
而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加
哪个内容等等。

•验收测试

客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件
是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间，最好能
将这些测试过程自动化。

•频繁地小规模发布软件（SmallReleases）

每个周期（Iteration）开发的需求都是用户最需要的东西。在XP中，对于每个周期完成时发布的系
统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说，
不再是看不见摸不着的东西，而是实实在在的。XP要求频繁地发布软件，如果有可能，应该每天都发布
一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。这些版本的
一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。

3简单设计，PairProgramming，测试驱动开发，重整和优化

XP程序员不但做为一个开发小组共同工作，还以两个人为一个小开发单元编写同一个程序。开发人员们
进行简单的设计，编写单元测试后再编写符合测试要求的代码，并在满足需求的前提下不断地优化设
计。

•简单设计

XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求，前提是按照这些简单设
计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何
画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯
穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求
模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不
断前进和发展的过程。从这个角度看，XP是把设计做到了极致。

•PairProgramming

XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实
施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因
此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。——这种工作方式
极大地提高了工作强度和工作效率。

很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。开始时总是不习惯的，而且两个人
的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统
计，在所有刚开始PairProgramming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高
效。

项目开发中，每个人会不断地更换合作编程的伙伴。因此，PairProgramming不但提高了软件质量，还
增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个
项目、开发队伍和公司。从这点看，PairProgramming不仅仅适用于XP，也适用于所有其它的软件开发
方法。

•测试驱动开发

反馈是XP的四个基本的价值观之一——在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中
提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等；
与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。
另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在往代码库中放程序
（CheckIn）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加
一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设
计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。这样，测试才能真正起到帮助
获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，
因此开发人员和客户可以得到尽可能充足的反馈。

•重整和优化(Refactoring)

XP强调简单的设计，但简单的设计并不是没有设计的流水帐式的程序，也不是没有结构、缺乏重用性的
程序设计。开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个
过程叫设计的重整和优化（Refactoring）。这个名字最早出现在MartinFowler写的《Refactoring:
ImprovingtheDesignofExistingCode》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring
的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP
强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不
应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，
保证新系统仍然符合预定的要求。

4频繁地整合，集体拥有代码（CollectiveCodeOwnership），编程规范

XP开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和PairProgramming以外，XP
要求每个人的代码都要遵守编程规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查
其他人写的代码。

•频繁地整合（Integration）

在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程
中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍
使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为
使用时间短，客户门心里并没有多少把握。

为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USERSTORY
（每次整合一个新的USERSTORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和
开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会
发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的
功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。

•集体拥有代码（CollectiveCodeOwnership）

在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。
因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代
码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代
码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被
发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代
码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开
发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。

为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可
以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。）

•编程规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为
有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现CollectiveCode
Ownership的重要前提之一。

5Metaphor（系统比喻），不加班

XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的，因
为这说明关于项目进度的估计和安排有问题。

•Metaphor（系统比喻）

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻
来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘
蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”

•不加班

大量的加班意味着原来的计划是不准确的，或者是程序远不清楚自己到底什么时候能完成什么工作。而
且，开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。XP认为，如果出现
大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计
划、进度和资源。