对于许多短暂接触过极限编程的人来说，XP 似乎是在呼吁软件设计的消亡。不仅许多设计活动被嘲笑为“前期大设计”，而且 UML、灵活框架甚至模式等设计技术也被淡化或完全忽略。事实上，XP 涉及很多设计，但它的方式与已建立的软件流程不同。XP 通过允许进化成为一种可行的设计策略的实践，重振了进化设计的概念。它还提供了新的挑战和技能，因为设计人员需要学习如何进行简单设计、如何使用重构来保持设计的整洁，以及如何以进化风格使用模式。

持续集成是一种软件开发实践，其中团队的每个成员至少每天将其更改与同事的更改一起合并到代码库中。每次集成都会通过自动构建（包括测试）进行验证，以便尽快检测到集成错误。团队发现，这种方法可以降低交付延迟的风险，减少集成工作量，并支持一些实践，这些实践可以培养健康的代码库，以便快速添加新功能。

重构是一种规范化的技术，用于重构现有的代码体，在不改变其外部行为的情况下改变其内部结构。其核心是一系列小的行为保持转换。每个转换（称为“重构”）作用不大，但这些转换的序列可以产生重大的重构。由于每次重构都很小，因此出错的可能性较小。每次重构后，系统都会保持完全正常运行，从而降低了系统在重构期间严重损坏的可能性。

如今，许多从事软件开发的人员都听说过结对编程的实践，但它在业界仍然只是零星采用。其接受程度不同的一个原因是，其好处并非立竿见影，它在中长期内会带来更多回报。而且它也不像“两个人在一台电脑上工作”那么简单，所以当它让人感到不舒服时，很多人会很快放弃它。然而，根据我们的经验，结对编程对于团队协作和高质量软件至关重要。

6 月下旬，一百多人聚集在地中海的撒丁岛，参加 XP2000 大会，讨论极限编程 (XP) 和其他灵活的方法论。

2002 年 5 月底，XP 社区再次降临地中海的撒丁岛。在本文中，我将介绍 Ken Schwaber、David Parnas、Enrico Zaninotto、Bill Wake 和 Standish Group 的 Jim Johnson 的全体演讲。他们让我对敏捷开发的本质、数学规范的作用、不可逆性的复杂性、隐喻以及大幅削减软件成本的最佳方式有了一些思考。

XP 的吸引人之处之一在于，它对您应该做什么才能进行 XP 做出了非常明确的说明。此外，这套实践经过精心设计，可以相互配合。删除任何内容都会产生严重的后果。然而，XP 和其他敏捷方法的原则之一是它们是自适应的：也就是说，您应该在开发项目时更改流程。这种概念如何与 XP 严格的实践相适应？

2001 年，当我去参加 Snowbird 会议时，Jim 采访了我，因为他正在写一本书，这次会议最终促成了敏捷宣言的诞生。它提供了一个关于我对极限编程的思考以及几天后我们称之为敏捷软件开发的东西的快照。

接受 Pearson 采访以宣传我们的书 规划极限编程。我们开玩笑地谈论了 XP 的背景以及计划在 XP 项目中的作用。

Kent Beck 在 1990 年代后期开发 极限编程 时提出了他的四条简单设计规则。我这样表达它们。

C3 是克莱斯勒综合薪酬项目的简称，这是克莱斯勒的一个工资项目，后来因成为 极限编程 的“诞生地”而闻名。

我遇到过各种代码所有权方案。我将它们分为三大类

这是关于敏捷方法的一个常见误解。它集中在用户故事的创建方式以及如何通过开发活动流动。误解是产品负责人（或业务分析师）创建用户故事，然后将它们交给开发人员实施。这种想法是，这是一个从产品负责人到开发的流程，产品负责人负责确定需要做什么，而开发人员负责如何做。

Daniel Terhorst-North 最近关于软件工艺的博客文章引发了许多博客讨论（如果您有兴趣，我在下面总结了这些讨论）。内容很多，但他的一个主题特别引起了我的共鸣，因此有了这篇文章。

极限编程 (XP) 是一种主要由 Kent Beck 开发的软件开发方法。XP 是最早的 敏捷方法 之一，事实上，XP 在 90 年代后期和 00 年代初期是占主导地位的敏捷方法，直到 Scrum 在 00 年代后期占据主导地位。许多人（包括我自己）认为 XP 是引起人们关注敏捷方法的主要催化剂，并且作为敏捷开发的起点优于 Scrum。

现场客户是极限编程的实践之一，是 白皮书 中提到的 12 种实践之一。它说客户应该与开发人员一起坐在他们的开放工作区，以便随时回答问题并与开发团队互动。事实上，他们是开发团队的一部分，并且认识到团队的成功既取决于他们，也取决于开发人员。他们不必为了做到这一点而放弃他们的日常工作，但他们必须亲自到场。

结对编程是一种软件开发实践，开发人员以两人一组的方式工作。所有重要的代码都是由两个程序员编写的，他们通常并排坐着，共用一个显示器，通常还共用一个键盘。在添加代码时，他们会一起讨论每个步骤。

关于 结对编程 的一些常见误解。

每个 XP 爱好者都知道 4 个价值观和 12 个实践，但有多少人知道 15 个原则？我承认，当 Kent 上周在 JAOO 上谈论它们时，我并不知道。演讲结束后，我问 Kent 关于它们的问题：“它们在 白皮书 中吗？”“是的，”他回答说，“巧妙地隐藏在名为‘基本原则’的章节中。”

自测试代码是我在 重构 中用来指代与功能软件一起编写全面的自动化测试的实践的名称。如果做得好，这将允许您调用一个执行测试的命令 - 并且您确信这些测试将发现隐藏在代码中的任何错误。

单元测试在软件开发中经常被提及，并且是我在编写程序的整个过程中都熟悉的一个术语。然而，像大多数软件开发术语一样，它的定义非常不明确，而且我发现，当人们认为它的定义比实际更严格时，往往会出现混淆。

当人们谈论极限编程时，他们通常关注的是其自适应的计划风格或演进式设计方法。但我尤其感兴趣的是一个规模虽小但正在增长的趋势，即越来越多的极限编程项目拥有极低的缺陷率，我指的是每月生产环境中出现 Bug 的数量少于一个。

速率是一个概念，它通过将广泛的工作量陈述与经过的时间联系起来，帮助校准计划。速率是指一个团队（如果是个人速率，则指个人）在一段时间内完成的工作量。您通常应该通过测量过去一段时间内完成的工作量来确定速率，遵循昨日天气原则。一种典型的方法是将过去三个时间段的速率平均，以确定未来时间段的速率。速率最初是作为极限编程的一部分而形成的，但后来得到了推广，现在广泛应用于各种形式的敏捷软件开发中。

这条原则认为，你今天完成的工作量将与你昨天完成的一样多。在迭代项目中，它表示您应该计划在本轮迭代中完成与上一轮迭代相同的工作量。这个术语来自极限编程社区。