极限编程
天下维客，你可以修改的网络知识库
极限编程
- 英文：XP，eXtreme Programming
- 是一种轻量级的软件工程方法学，它是敏捷软件开发中最流行的方法,由肯特·贝克，沃德·坎宁安和罗恩·杰弗里斯提出。 肯特·贝克在1999年写了第一本关于极限编程的书《极限编程解析》，2005第二版出版。
该书阐述了如下的极限编程的哲学思想 ：
- 一种社会性的变化机制
- 一种开发模式
- 一种改进的方法
- 一种协调生产率和人性的尝试
- 一种软件开发方法
把极限编程一般化并用于其他类型的项目称为极限项目管理。
目录 |
XP 核心的实践
极限编程实践操作的核心，正如 Extreme programming explained 所描述的，可以被区分为以下四个范围（12个实践操作）:
小规模反馈
- 测试驱动发展
- 策划游戏
- 全队（原名：在场客户）
- 结对编程
持续的过程而不是批量的
- 持续整合
- 设计优化（原名：软件重构）
- 小型发布
共同认识（共识）
- 简单的设计
- 系统隐喻
- 集体代码所有
- 编程标准/编程规约
编程员的利益
- 恒定速路
- 可持续的速率（原名：每周40小时）
在第二版的Extreme programming explained中，在主要实践之外，还列出了一系列延伸的实践。
尊重
方法
快速反馈
is in production.
假设简单
假设简单认为任何问题都可以"极度简单"的解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样作。
增量变化
融入变化
活动
编码
测试
没有经过测试的代码什么都不是。如果你没有测试，客户可能感觉不到，很多软件在发布的时候没有经过完整的测试，它们还都在工作（或多或少的工作）。 在软件开发过程中，极限编程认为，如果一个函数没有经过测试就不能认为它可以工作。 This raises the question of defining what one can be uncertain about.
- You can be uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete.
- You can be uncertain whether what you meant is what you should have meant. To test this uncertainty, XP uses acceptance tests based on the requirements given by the customer in the exploration phase of release planning.
倾听
设计
实践
策划游戏
在极限编程中主要的策划过程称为策划游戏。 本节将通过过程模型介绍这个过程。
策划过程分为两部分：
Exploration phase － Release planning
提交状态 － 发布计划
这一阶段涉及成本、利润和计划影响这三个因素，包含四个部分：
- 按照价值排序：业务方按照商业价值为用户故事排序。
- 按风险排序：开发方按风险为用户故事排序。
- 设定周转率：开发方决定以怎样的速度开展项目。
- 选择范围：挑选在下一个发布中需要被完成的用户故事，基于用户故事决定发布日期。
价值排序
业务方按照商业价值为用户故事排序。它们会被分为三类：
- 关键：没有这些故事系统无法运作或变得毫无意义。
- 重要的商业价值：有重要业务价值的非关键用户故事。
- 最好能有：并没有重要商业价值的用户故事；例如在可用性或用户界面上的改进。
风险排序
程序员按照风险对用户故事进行排序。他/她们将用户故事的风险划分成三类：低、中、高。以下是这种方式的一个范例：
- 决定风险索引：依照以下因素给每个用户故事一个0到2的索引：
- 完全度（我们是否已经了解所有的故事细节？）
- 完全（0）
- 不完全（1）
- 未知（2）
- 发散性（可能会发生变化吗？）
- 低（0）
- 中（1）
- 高（2）
- 复杂度（是否难以构建？）
- 简单（0）
- 标准（1）
- 复杂（2）
- 完全度（我们是否已经了解所有的故事细节？）
为每个用户故事增加所有这些索引后，给这些用户故事指定一个风险索引：低（0–1），中（2–4），高（5–6）。
激励状态 － 发布计划
在操作阶段开发人员和业务人员可以“操纵”整个过程。这意味着，他们可以做出改变。个体的用户故事，或者不同用户故事的相对优先级，都有可能改变；预估时间也可能出现误差。这是做出相应调整的机会。
探索阶段- 迭代计划
迭代计划中的探索阶段是关于创建任务和预估实施时间。
- 收集用户故事：收集并编写下一个发布的所有用户故事。
- 组合/拆分任务：如果程序员因为任务太大或太小而不能预估任务完成时间，则需要组合或拆分此任务。
- 预估任务：预测需要实现此任务的时间。
约定阶段 - 迭代计划
在迭代计划的约定阶段以不同用户故事作为参考的任务被指派到程序员。
- 程序员接受任务：每个程序员都挑选一个他/她负责的任务。
- 程序员预估任务：由于程序员对此任务负责，他/她必须给出一个完成任务的估计时间。
- 设定负载系数：负载系数表示每个程序员在一个迭代中理想的开发时间。比如：一周工作40小时，其中5小时用于开会，则负载系数不会超过35小时。
- 平衡：当团队中所有程序员都已经被分派了任务，便会在预估时间和负载系数间做出比较。任务分派在程序员中达到平衡。如果有一个程序员的开发任务过重，其他程序员必须接手他/她的一部分任务，反之亦然。
操作阶段 - 迭代计划
各个任务是在迭代计划的操作阶段中一步步实现的。
- 获取一张任务卡片：程序员获取一张由他/她负责的任务的卡片。
- 找寻一名同伴：这个程序员将和另一位程序员一同完成开发工作。这在实施结队编程中会做更深入的探讨。
- 设计这个任务：如果需要，两位程序员会设计这个任务所达成的功能。
- 编写单元测试：在程序员开始编写实现功能的代码之前，他/她们首先编写自动测试。这在实施单元测试中会做更深入的探讨。
- 编写代码：两位程序员开始编写代码。
- 运行测试：运行单元测试来确定代码能正常工作。
- 运行功能测试：运行功能测试（基于相关用户故事和任务卡片中的需求）。
结对编程
结对编程的意思是所有的代码都是由两个人坐在一台电脑前一起完成的。一个程序员控制计算机并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。
结对不是固定的: 我们甚至建议程序员尽量交叉结对。这样，每个人都可以知道其他人的工作，每个人都对整个系统熟悉，结对编程加强了团队内的沟通。 (这与代码集体所有制是息息相关的).
集体所有制
集体所有制意味着每个人都对所有的代码负责；这一点，反过来又意味着每个人都可以更改代码的任意部分。结队编程对这一实践贡献良多：借由在不同的结队中工作，所有的程序员都能看到全部的代码。集体所有制的一个主要优势是提升了开发过程的速度，因为一旦代码中出现错误，任何程序员都能修正它。
在给予每个开发人员修改代码的权限的情况下，可能存在程序员引入错误的风险，他/她们知道自己在做什么，却无法预见某些依赖关系。完善的单元测试可以解决这个问题：如果未被预见的依赖产生了错误，那么当单元测试运行时，它必定会失败。
现场客户
在极限编程中，“客户”并不是为系统付帐的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。
单元测试
单元测试是用以测试一小段代码的自动测试（例如：类，方法）。在极限编程中，在代码编写前就编写单元测试。这种方式的目的是激励程序员设想他/她的代码在何种条件下会出错。极限编程认为当程序员无法再想出更多能使他/她的代码出错的情况时，这些代码便算完成。
重构
由于XP教条提倡编写程序时只满足当前的需求，并且以尽可能简单的方式实现。有时会碰上一套僵硬的系统，所谓僵硬的系统，表现之一是需要双重（或多重）维护：功能变化需要对多份同样（或类似）的代码进行修改；另一种表现是对代码的一部分进行修改时会影响其它很多部分。XP教条认为当这种情况发生时，意味着系统正告诉你通过改变系统架构以重构代码，使它更简单、更通用。参见重构。
具争议性的问题
极限编程的特征
极限编程方法的基本特征是：
- 增量和迭代式的开发 - 一次小的改进跟着一个小的改进。
- 持续的，通常是自动重复的单元测试，回归测试。参见JUnit。
- 结对编程
- 在程序设计团队中的用户交互（在场的客户）
- 软件重构
- 共享的代码所有权
- 简单
- 反馈
- 用隐喻来组织系统
- 可以忍受的速度
这些特性来源于那些被认为是有效的原则，并把它们发挥到极致：
- 开发人员和客户之间的交互是有益的. 因此,一个极限编程的小组从理论上要求需要一个软件用户在身边,该用户制定软件的工作需求和优先级, 并且尽可能在各种问题出现的时候马上就能回答.
- 如果学习是好的, 那么就把它做到底: 这样减少了开发和反馈周期的长度,测试也能更早完成.
- 简单的代码更可能工作。所以极限编程的程序员在一个软件项目中只写出能够满足当前实际需求的代码,这样或多或少降低了代码的复杂性和重复性.
- 如果简单的代码是好的, 那么把变得复杂的代码改写成简单的.
- 代码评审是好的。因此,极限编程的程序员以两人搭档的方式工作. 他们共享一个屏幕和键盘,增加了队员之间的交流,也让代码在一被写出的时候就被人评审了.
- 测试代码是好的。因此,在极限编程中,测试用例在实际代码之前就被写出来了. 代码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软件系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.
一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其他人认为统一软件过程更适合大的团队。然而,极限编程在一些超过100人的开发小组中获得成功. 并不是极限编程不能够推广到更大的团队,而是很少有更大的团队来试着用它. 极限编程的人员也拒绝去随便推测这个问题.
争论的观点
极限编程也有其被争论的一面：
绝大多数设计活动都匆匆而过，并渐进式的，开始一个“最简单的可能工作的东西”并当其需要时（测试失败）才增加复杂性。单元测试促成为了设计纪律。
极限编程中的沟通
构建软件系统的一个基本任务是向系统的开发人员传达系统的需求。在形式的软件开发方法学中，沟通是通过文档完成的。
极限编程方法可以被看作为在开发团队成员间快速构建和散布统一的知识的一种方法。目的在于给所有开发人员一个共享的关于系统的看法，这个看法与用户持有的看法相一致。为了这个目的，极限编程热衷于简单的设计，隐喻，用户与程序员之间的合作，频繁的口头沟通和反馈。
参见:
参考资料
- 肯特·贝克：《极端编程解析：拥抱变化》， Addison-Wesley, <a href="/index.php?title=Special:Booksources&isbn=0201616416" class="internal">ISBN 0201616416</a>
- 阿里斯代尔·寇本：《敏捷软件开发》，Addison-Wesley, <a href="/index.php?title=Special:Booksources&isbn=0201699699" class="internal">ISBN 0201699699</a>
- 雷剑文 陈振冲 李明树：《超越传统的软件开发－－极限编程的幻象与真实》, 电子工业出版社, <a href="/index.php?title=Special:Booksources&isbn=712100657X" class="internal">ISBN 7-121-00657-X</a>
外部连接
- 沃德·坎宁安的网站，极限编程，关于极限编程和相关主题的更多信息。
- 面向客户的极限编程介绍
- 罗恩·杰弗里斯的网络杂志XProgramming.com - 极限编程资源
- ExtremeProgramming.org
- 马特斯蒂芬斯的批评网站，对极限编程的问题的深邃的批评 （参见该页得到更多对极限编程的批评的链接）
- 马丁·福勒论极限编程
- 结对编程，极限编程实践
- 敏捷软件开发的宣言
- 工具: "XPlanner"
- 工具: "XPWeb"
- 来自CiteSeer的引文
- 来自方法与工具杂志的文章脱离极限编程的极限编程测试：利用敏捷测试实践的优势
- 来自方法与工具杂志的文章 结对编程真能改进你的项目？
