敏捷开发小知识8再讲XP极限编程

Posted 2021-04-25 科技咖姐

作为开发人员，我们应该记住，XP并非惟一选择。

---Pet MaBreen

极限编程（eXtrem Programming简称XP）是敏捷方法中最著名的一个，它由一系列简单即互相依赖的实践组成，这些实践结合一起形成了一个胜于部分结合的整体。下面介绍这14个实践（在后面的很多书有提出12或13个实践，为对实践进行了调整）

1.客户作为团队成员。

最好的情况是客户和开发人员在同一房间工作，次一点的情况是客户和开发人员之间的工作距离在100米以内。距离越大，客户就越难成为真正的团队成员。

如果实在无法和客户在一起工作，建议他们在一起工作，愿意并能代替真正客户的人。

2.用户素材（ User stories也叫用户故事)

为了进行项目计划，了解需求只需要做到能估算它的程度就够了。你必须知道存在很多的细节。也必须知道需求的大致分类，但是不需要知道特定的细节。

过早的了解低优先级的需求时，很可能会导致做无用功以及对需求不成熟的关注。

User stories就是正在进行的关于需求谈话的助记符，它是一个计划工具，客户可以使用它并根据它的优先级排优来估算工时。

3.短交付周期。

XP建议的交付频率是2周一个迭代。在每个迭代结束时给相关方演示生成的系统并得到他们的反馈。

3.1迭代计划

迭代的需求由客户依据开发的估算，选择的一些User stories。一旦迭代开始，就不允许更改User stories。但开发可将User stories拆分为Task，并依技术评估的顺序进行开发。

3.2 发布计划

XP会创建一个计划来规划随后的约6次迭代的内容（时间建议为3个月），这就是发布计划。为一个功能集较大的交付。在此注意的是这些发布计划是由一组客户排优的。

注意发布计划不是一成不变的，客户原则上可以改变发布计划，但是不能改变迭代计划。

4.验收测试

User Stories中会有测试验收实例。 一旦通过测试验收的项目。 应该加到已完成项，而且不能再失败。

系统不能工作状态时间决不能超过几个小时。

5.结对编程（Pair Programe)

结对编程的程序员中的一位控制键盘并输入代码，另一位观察输入的代码中的错误和可以改进的地方。两个人强烈地进行交互，并全身心地投入到软件的编写中。

结对编程，每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其它的团队成员在一起工作过。并且他们应该参与了本次迭代中涉及的每项工作。

这将极大的促进知识在团队成员中传播。 稀缺专业模块都需要合适的专家去完成，但是那些专家几乎会与团队其它人结对过。这将加快专业知识在团队中的传播。这样子，在紧要关头，其它团队成员就能代替所需要的专家了。

研究表明，结对不会降低开发团队的效率，而且会大大减少缺陷率。

6.测试驱动开发（TDD）

这是有关测试的内容。首先先编写一个单元测试，由于它要测试的功能还不存在，所以它的运行是失败的，然后编写完此模块的代码后可测试通过。 这里非常有利于重构。

写测试用例与代码的迭代速度是很快的，基本上几分钟，用例与代码共同开发。其中用例可对代码的编写进行指导。

当为了使测试用例通过而编写代码时，这样子的代码就定义为可测试的代码。这样子会强烈地激发程序员去解耦，这样子能单独对它们进行测试。

因而，以这种方式编写的代码设计耦合性比较弱，面向对象的设计原则在进行这种解除耦合方面具有巨大的帮助作用。

7. 集体所有权

结对编程中的每一对都具有拆出（checkout)，任何模块并对它进行改进的权力 。没有程序员对单一代码负责。每个人都参与GUI方面的工作，这不意味着去专家去权威。

8.持续集成

XP团队使用非阻塞的源代码控制工具。程序员可以在任何时候拆出任务模块，而不管是否有其它人已经拆出这个模块。结对编程保证每个拆出又合入的代码可以通过测试。一旦测试通过，表明拆入工作完成。

XP团队每天都会多次系统构建，他们会重新创建整个系统。

9.可持续的开发速度

项目不是一次全速跑，是马拉松长跑。团队必须有意识地保持一种稳定、适中的速度。

Xp的规则为不允许加班，宣导40H/周的工作速率，但是发版本除外。

10.开发的工作空间

团队在一个大通间工作，房中有几台服务器，有适合结对编程足够宽的桌子，墙壁上挂满了状态图表、任务明细表、UML图等。

每个人了解对方的工作状态 ， 有人会认为这种吵杂的环境会影响开发进度，但密 歇根 大学的一项研究表明 ： 在充满积极讨论的屋子（war room)里工作，生产率真非但不会降低，反而会成倍地提高。

11.计划游戏

计划游戏的本质是划分业务人员和开发人员之间的职责。业务决定特性(Feature)的重要性。开发评估开发这些特性所需要的时间。

通过这些简单的规则，采用短周期迭代和频繁的发布，很快客户和开发人员会适应项目的开发节奏，基于这种了解，客户也能确定项目会持续多长时间，及会花费多少成本。

12.简单的设计

XP团队使他们的设计尽可能地简单、具有表现力（expressive)。在一次次迭代中，团队不断调整开发，使最优先的需求提前被开发。 下面三条XP指导原则（Mantras)可以对开发进行指导。

12.1 考虑能够工作的最简单的事情

Xp总是尽量找到可以实现最优先的需求最简单的设计。

12.2 你将不需要它

是 ，总有一天会用于数据库，会ORB，总有一天得去支持多用户，但是在没有迹像表明现在就需要的时候，不需要引入。

12.3 一次，并且只有一次

XP不能容忍有重复的代码。无论在哪里发现重复的代码，都会消除。去除的办法是抽像。消除重复的行为会迫使团队提炼出许多抽象，并进一步减少代码间的耦合。

13.重构

代码往往会腐烂，XP团队会经常通过重构的方法来扭转这个退化。重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。每个改造都是小的进步，加起来就是对系统设计和构架显著的改进。

改造后，运行单元测试确保改造没有引入破坏 ，然后再去做下一次改造。

每次改进都需要进行行测试。

重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班时才进行。重构是我们每隔一小时或半小时就要去做的事。通过重构，我们可以持续地保持尽可能干净、简单具有表现力的代码。

14.隐喻

是所有XP中最难理解的一个。在某种意义上来讲，隐喻是XP实践中最重要的实践之一。

隐喻是将整个系统联系在一起的全局视图；它是系统的未来景像，使得所有单独模块的位置与外观变得明显直接。

隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成的元素的词汇表，有助于定义它们之间的关系。

举例：如做一个文本投屏系统，装卸卡车比喻整个系统，缓冲区是小卡车，屏幕是垃圾场，程序是垃圾制造者，有助于我们理解整个系统。

小结

XP极限编程是一组简单、具体的实践，这些实践结合在一起，就形成了敏捷开发的过程。这些过程在很多团队都使用过，并取得了很好的效果。XP是一种优良、通用的软件开发方法。项目团队可以直接拿过来用，也可以增加一些实践，或对基本的实践进行修改后使用。

说明：本文章及图片为《敏捷软件开发 原则、模式与实践》读书笔记，向大师们致敬。如有侵权，请联络本人删除。

-End-