目录
1：PDF上传链接
2.1：极限编程实践
极限编程（简称XP）是敏捷方法中最著名的一个。它由一系列简单却相互依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。本章节我们将简要的探讨一下这个整体。
2.1.1：客户作为团队成员
我们希望客户跟开发人员在一起紧密的工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。
谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。
最好的情况是客户和开发人员在同一个房间中工作，次一点就是客户和开发人员之间的工作距离在100米内，距离越大，客户就越难成为真正的团队成员。
如果无法和客户一起工作，建议去找一个能在一起工作，愿意并能够代替真正客户的人。
2.1.2：用户素材
为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。必须要知道存在很多细节，也必须知道细节的大致分类，但是你不必知道特定的细节。
用户素材就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
2.1.3：短交付周期
XP项目每周交付一次可以工作的软件。每两周的迭代（可称为重复周期或循环周期）都实现了涉众的一些需求。在每次迭代结束时，会给涉众演示迭代生成的系统，以得到他们的反馈。
1.迭代计划
每次迭代通常耗时两周。一旦迭代开始，客户就同意不再修改当次迭代中用户素材的定义和优先级。迭代期间，开发人员可以自由地将用户素材分解成任务，并依据最具体技术和商务意义的顺序来开发这些任务。
2.发布计划
XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。一次发布通常需要3个月的工作。
发布计划不是一成不变的，客户可以随时改变计划的内容。他可以取消用户素材，编写新的用户素材，或者改变用户素材的优先级别。
2.1.4：验收测试
可以以用户指定的验收测试形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户素材之前或用户素材的同事进行编写的。
2.1.5：结对编程
所有的产品代码都是由结对的程序员使用同一台电脑共同完成的。结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找代码中的错误和可以改进的地方，两个人强烈地进行交互，他们都全身心地投入到软件的编写中。
结对关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代所涉及的每项工作。
这将极大的促进知识在团队中的传播。在紧要的关头，其他团队成员能够替代所需要的成员。
laurie williams和nosek的研究表明，结对非但不会降低开发团队的效率，而且会大大减少缺陷率。
2.1.6：测试驱动开发方法
后续比较的第4张市关于测试方面的内容。
编写测试用例和代码之间的更迭速度是很快的，基本上几分钟左右。测试用例和代码共同演化。其中测试用例循序渐进地对代码的编写进行指导。（参考第6章）
作为结果，一个非常完整的测试用例集就和代码一起发展起来，程序员可以使用这些测试来检查程序是否正确工作，如果结对的程序员进行了小的更改，那么他们可以进行测试，以确保更改没有对程序造成任何破坏，这会非常有利于重构。
2.1.7：集体所有权
结对编程中的每一对都具有拆出任务模块并对它进行改进的权力。没有程序员对任务一个特定的模块或技术单独负责。每个人都参加GUI方面的工作，中间件、数据库。没有人比其他人砸一个模块或技术上具有更多的权威。
这不意味着XP不需要专业知识。如果你的专业领域是有关GUI的，那么你最有可能从事GUI方面的任务，但是也会被邀请结对去从事中间件、数据库方面的任务。也可以去学其他方面的专业知识，然后从事其他任务，不会被限制在自己的专业领域。
2.1.8：持续集成
程序员每天会多次拆入（check in）他们的代码并进行集成，规则很简单。第一个拆入的只要完成拆入就可以了，所以其他的人负责代码合并（merge）工作。
XP团队使用非阻塞的（nonblocking）源代码控制工具。
结对人员会在一项任务上工作1-2个小时。创建测试用例和产品代码。过程中会对代码进行拆入、合并，测试。
2.1.9：可持续的开发速度
软件项目不是全速的短跑，它是马拉松长跑，团队必须要有一种可持续的速度前行，保持旺盛的精力和敏锐的警觉，必须要有意识的保持稳定、适中的速度。
XP的规则是不允许团队加班工作。在发布前的一个星期是该规则的唯一例外。如果发布的目标就在眼前并且能够一蹴而就，则允许加班。
2.1.10：开放的工作空间
团队在一个开放的房间中一起工作，房间中有一些桌子，每张桌子摆放两到三台工作站，每台工作站前有给结对编程人员预备两把椅子，墙上挂满状态表、任务明细、UML图等。
在“充满积极讨论的屋子（war room）”里工作，生产效率非但不会降低，反而会成倍地提高。
2.1.11：计划游戏
在下一章“计划”中，会详细的介绍XP的计划游戏方面的内容。这里先简要的描述一下。
计划游戏的本质是划分业务人员和开发人员直接的职责，业务人员（也就是客户）决定特性的重要性，开发人员决定实现一个特性所花费的代价。
在每次发布和每次迭代的开始，开发人员基于在最近一次迭代或者最近一次发布中他们所完成的工作量，为客户提供一个预算。客户选择那些所需的成本合计起来不超过预算的用户素材。
依据简单的规则，采取短周期的迭代和发布，客户会了解到开发人员的开发速度。基于这些了解，客户能够确定项目会持续多长时间，以及会花费多少成本。
2.1.12：简单的设计
XP团队使他们的设计尽可能地简单、具有表现力。此外他们仅仅关注与计划在本次迭代中要完成的用户素材。在迭代的过程中，他们还不断地变迁系统设计，使之队正在实现的用户素材而言始终保持在最有的状态。
这意味着XP团队的工作不会从基础结构开始，他们可能并不先去使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方式实现第一批用户素材。只有当出现一个用户素材迫切需要基础机构时，他们才会引入该基础结构。
下面三条XP指定原则（mantras）可以对开发人员进行指导
1.考虑能够工作的最简单的事情
XP团队尽可能使用简单的方式来实现当前的用户素材，能有单线程就不用多线程，能用socket连接，就不用ORB（对象请求代理）或者RMI（远程方法调用）；
2.你将不需要它
只有在足够的理由的情况下，团队才会引入这些基础结构。
3.一次，并且只有一次
极限编程着不能容忍重复的代码，无论在哪里发现重复的代码，他们都会消除它们。
重复代码最容易出现就是用鼠标选中一段代码，然后进行粘贴，当发现重复代码，我们就会通过定义一个函数或者基类方法来清除他们。有时候两个或多个算法非常相似，但是他们之间存在着微妙的差别，我们会把它们变成函数，或者使用TEMPLATE METHOD模式。无论是哪一种代码重复之源，一旦发现，就必现被消除，消除的同时，还要进一步减少代码的耦合。
2.1.13：重构
重构就是在不改变代码行为的前提下，对其进行一些列小的改造。
重构是持续进行的，通过重构，我们可以持续的保持尽可能干净、简单并且具有表现力的代码。
2.1.14：隐喻
隐喻（metaphore）是所有XP实践中最难理解的一个，极限编程者在本质上都是务实主义者，隐喻这个缺乏具体定义的概念使我们觉得很不舒服。的确，一些XP的支持者经常讨论把隐喻从XP的实际中去除，然而，在某些意义上，隐喻确实XP所有实践中最重要的实践之一。
隐喻通常可以归结为一个名字系统，这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间的关系。
2.2：结论
极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法。
1591
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
