敏捷开发-极限编程（XP）

本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。

定义

极限编程是一种软件开发框架，旨在生产出高质量的软件同时保证开发团队有高质量的生活状态，更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。

• 目标

极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更将导致开发成本急速增加，而这样的需求变更在一些发展极快的领域中是不可避免的。

哲学思想：

• 一种社会性的变化机制
• 一种开发模式
• 一种改进方法
• 一种协调生产率和人性的尝试
• 一种软件开发方法

极限编程通过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

极限编程（XP）核心实践

极限编程一共包含 12 个核心实践，分为持续程序、细微反馈、共识、程序员利益四个方

持续程序

1 持续集成

集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

2 软件重构

由于极限编程教条提倡编辑程序时只满足目前的需求，并且以尽可能简单的方式实现。有时会碰上一套僵硬的系统，所谓僵硬的系统，表现之一是需要双重（或多重）维护：功能变化需要对多份同样（或类似）的代码进行修改；另一种表现是对代码的一部分进行修改时会影响其它很多部分。XP 教条认为当这种情况发生时，意味着系统正告诉你通过改变系统架构以重构代码，使它更简单、更泛用。

3 短周期交付

极限编程和 Scrum 一样采用迭代的交付方式，每个迭代 1-3 周时间。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

细微反馈

4 结对程序设计

结对程序设计的意思是所有的代码都是由两个人坐在一台电脑前一起完成的。一个程序员控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。结对不是固定的：我们甚至建议程序员尽量交叉结对。这样，每个人都可以知道其它人的工作，每个人都对整个系统熟悉，结对程序设计加强了团队内的沟通。

5 策划游戏

XP 的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。针对这两个问题，XP 中又两个主要的相应过程：

• 软件发布计划（ReleasePlanning）

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

• 周期开发计划（IterationPlanning）

在开发过程中，将一个长周期的大型的软件拆分成多个开发计划，每个计划都产生经过测试的能够独立交付的软件。每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。XP 的这种做法是为了及早发现问题、解决问题。

6 测试驱动开发

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

测试驱动开发的基本过程如下：

1. 快速新增一个测试；
2. 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过；
3. 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法；
4. 运行所有的测试，并且全部通过；
5. 重构代码，以消除重复设计，优化设计结构。

7 全队（在场客户）

在极限编程中，“客户”并不是为系统付账的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。

共识

8 编码标准

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

9 代码集体所有

集体所有制意味着每个人都对所有的代码负责；这一点，反过来又意味着每个人都可以更改代码的任意部分。结队程序设计对这一实践贡献良多：借由在不同的结队中工作，所有的程序员都能看到完全的代码。集体所有制的一个主要优势是提升了开发程序的速度，因为一旦代码中出现错误，任何程序员都能修正它。

10 简单设计

XP 要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。在 XP 中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在 XP 中，设计过程几乎一直贯穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看，XP 是把设计做到了极致。

11 系统隐喻

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

程序员利益

12 可持续发展

团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

极限编程价值

• 沟通

极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。

• 简单

极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。

• 反馈

1. 来自系统的反馈

通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。

1. 来自客户的反馈

功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。

1. 来自小组的反馈

当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。

• 勇气

只为目前的需求设计以及编码，别为不可预期的未来做太多考虑”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。

• 尊重

在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试案例失败、或者以其他方式导致工作延期。

极限编程规则

计划

• 编写用户故事。
• 根据发布计划制定发布时间表。
• 进行频繁的小规模发布。
• 将项目分解成迭代。
• 用迭代计划驱动每个迭代。

管理

• 为团队提供专注开放型办公空间。
• 可持续的节奏。
• 以站会开始每一天。
• 团队开发速度可度量。
• 让团队坐在一起。
• 调整有缺陷的规则。

设计

• 简单原则。
• 设定一个系统隐喻。
• 在设计交流中使用 CRC 卡。
• 使用 Spike 方法降低风险。
• 不要过度设计或过早添加不必要的功能。
• 尽可能地重构代码。

编程

• 客户紧密参与团队协作。
• 遵循编码规范。
• 优先编写测试。
• 通过结对编程构建生产代码。
• 一次仅限一对程序员集成代码。
• 持续集成。
• 选一台机器专用于代码集成。
• 代码集体所有。

测试

• 所有代码都必须有单元测试。
• 发布前必须跑通所有单元测试。
• 发现一个 Bug 要增加一个单元测试。
• 经常性进行验收测试并公布测试结果。

极限编程原则

组成极限编程基础的原则，正是基于上面描述的那几条价值。在系统开发项目中，这些原则被用来为决策做出指导。与价值相比，原则被描述的更加具体化，以便在实际应用中更为简单的转变为具体的指导意见。

• 快速反馈

当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。

• 假设简单

假设简单认为任何问题都可以“极度简单”地解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。

• 包容变化

“包容变化”这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。

• 增量变化

极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。

• 高质量工作

没人喜欢拖泥带水，每个人都期望出色的完成工作。极限编程的提倡者认为范围、时间、成本和质量这个四个软件开发的变量，只有质量不可妥协的。

总结

XP 是一个实践性非常强的框架，非常注重软件工程和软件质量，认同需求的快速变化，强调适应性。XP 的核心实践成为众多团队开发人员的行动指南和行为准则，是指导开发人员的日常实践的良方，例如持续集成、结对编程、测试驱动开发、重构、单元测试、编码规范、代码集体所有等被广泛接受和实践。

《数字化 IT 从业者知识体系》背景 数字化和可持续发展是中国企业未来发展的两大主题，掌握数字化知识，具备数字化能力，应用数字化技术是我们 IT 从业者未来核心竞争力所在。《数字化 IT 从业者知识体系》的初衷是为IT从业者提供的系统性的数字化知识体系，内容涵盖管理实践、工程实践、技术实践三个层次，涉及软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四大方面。 在接下来的《数字化 IT 从业者知识体系》系列文章，何文强将从软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四个方面，为大家进行逐一分享介绍：

1. 软件开发方法主要包括瀑布、敏捷、精益等；
2. 应用技术架构主要包括微服务架构、服务网格架构、无服务器架构、分布式多运行架构等；
3. 应用部署与管理主要包括但不限于虚拟化技术、容器技术与容器编排等；
4. 软件交付与协作主要包括但不限于CMMI、ITIL、DevOps等。

相信该知识体系有利于 IT 从业者构建丰富的技术体系、全面的技术视野和系统的能力建设。欢迎大家前往《数字化 IT 从业者知识体系》话题进行详细阅读。