如果单独执行极限编程实践，可能会很弱，因此可能会失败。在极限编程中，所有实践都需要作为一个整体来考虑，以便它们相互支持。一个人的弱点被另一个人的优点所掩盖。

在本章中，我们将重点介绍如果孤立实施每种做法可能存在的缺点。我们将看到极限编程与其他实践一起实施时，如何能够支持该实践克服弱点。

规划游戏–其他XP实践的支持

在本节中，我们将看到Planning Game的弱点以及其他XP实践如何支持它。

规划游戏–劣势

规划游戏的缺点是，您可能无法仅凭一个粗略的计划来开始开发，也无法不断更新该计划，因为这可能会花费太长时间并使客户不安。

与其他XP实践结合的规划游戏

其他XP实践以以下方式支持规划游戏-

• 在计划游戏中，客户还基于开发人员提供的估算来参与更新计划。

• 您发布简短信息，以便计划中的任何错误最多影响几周或几个月。

• 您的客户坐在团队中，因此他们可以快速发现潜在的变化和改进的机会(在线客户)。

• 持续测试可帮助开发人员和客户立即确定需要什么。

因此，您可以从一个简单的计划开始开发，并在进行过程中不断完善它。

简短版本–其他XP实践的支持

短版–缺点

几个月后您可能无法投入生产。您当然不能在每天到每几个月的周期内发布系统的新版本。这是因为您需要花费时间来吸收新的需求，即对当前代码进行更改。

其他XP实践的简短发布。

其他XP惯例通过以下方式支持短版-

• 策划游戏可帮助您处理最有价值的故事，因此即使是小型系统也将具有商业价值。

• 持续集成使打包发布的成本降至最低。

• 测试可以充分降低缺陷率，因此在发布之前不需要漫长的测试周期。

• 您可以设计一个简单的设计来满足此发行版的需求，而不是一直都这样。

因此，您可以在开发开始后立即发布短期发行版。

隐喻–其他XP实践的支持

您不可能仅凭一个隐喻就可以开始开发。那里可能没有足够的详细信息，您可能错了。

其他XP实践的隐喻

其他XP实践以以下方式支持Metaphor-

• 使用结对编程，您将获得来自已实现代码的快速具体反馈，并测试隐喻是否工作正常。

• 您的现场客户很乐意用隐喻来谈论系统。

• 连续重构使您可以更好地理解隐喻在实现中的含义。

• 简单的设计可以帮助您与隐喻进行映射。

因此，您可以仅用一个隐喻来开始开发。

简单设计–其他XP实践的支持

设计简单-缺点

您可能无法为当今的代码提供足够的设计，并且您的设计可能无法继续发展该系统。

其他XP惯例的简单设计。

其他XP实践以以下方式支持简单设计-

• 重构允许您进行更改。

• 从总体上来说，您可以确定未来的设计变更将趋于趋同。

• 结对编程可帮助您确信自己正在设计一个可行的简单设计。

• 每周40小时可帮助您专注于正确的设计。

• 连续的单元测试和客户测试可确保您的简单设计步入正轨。

因此，您可以进行当今最佳的设计，而无需进行猜测。

测试–其他XP实践的支持

测试-缺点

您可能会认为-

• 您不可能编写所有这些测试。

• 编写测试可能会花费太多时间。

• 开发人员不会编写测试。

使用其他XP实践进行测试

其他XP实践以下列方式支持测试-

• 简单的设计使编写测试变得容易。

• 重构使您可以决定需要哪些测试。

• 使用结对编程，即使您无法想到其他测试，您的伴侣也可以。您可以允许您的伴侣运行移交键盘的测试，当您看到测试全部在运行时，您会充满信心。

• 集体所有权可确保具有所需技能的开发人员可以在任何复杂的部分上进行编码和测试。

• 持续集成并立即运行一对对所做的每组更改的测试，可确保-

  • 如果100％的测试通过，则新代码有效，或者

  • 如果任何测试失败，则是该对代码使系统失败，从而使更改可以立即撤消，并且该对可以重新开始编写代码，并清楚地说明了它们所实现的功能。

• 简短的发行版可确保客户可以使用一个工作系统来运行测试并提供反馈。

• 在线客户将有时间运行所有测试并立即在工作系统上提供反馈。

• 规划游戏可确保在测试后从客户那里获得反馈，以计划下一个版本。

因此，开发人员和客户将编写测试。此外，测试是自动化的，以确保其余的极限编程都能正常工作。

重构–其他XP实践的支持

重构-缺点

您不可能一直都在重构系统的设计。它会-

• 花太长时间

• 太难控制了，并且

• 最有可能破坏系统。

使用其他XP惯例进行重构

其他XP实践以下列方式支持重构-

• 使用集体所有权，您可以在任何需要的地方进行更改。

• 使用编码标准，您无需在重构之前重新格式化。

• 使用结对编程，您可以勇于应对艰难的重构。

• 通过简单的设计，重构更加容易。

• 通过隐喻，您可以轻松进行交流。

• 通过测试，您不太可能在不知不觉中破坏某些东西。

• 通过持续集成，如果您不小心破坏了某些内容，或者您的重构与其他人的工作冲突，那么您将在几个小时内就知道了。

• 每周工作40个小时，您就会得到休息，因此您更有勇气，而且很少犯错误。

因此，只要有机会，您就可以重构–

• 使系统更简单

• 减少重复

• 沟通更清晰

配对编程–其他XP实践的支持

结对编程-弱点

您可能无法成对编写所有代码。太慢了。如果两个人相处得不好，就会使情况变得困难。

将编程与其他XP实践结合使用。

其他XP实践以以下方式支持结对编程-

• 编码标准减少了冲突。

• 通过40小时的工作，每个人都变得新鲜而专注，从而进一步减少了不必要的讨论的机会。

• 两人一起编写测试，使他们有机会在解决实现部分之前调整他们的理解。

• 隐喻可帮助两人确定其有关命名和基本设计的决定

• 简单的设计使这对夫妇有一个共同的理解。

• 重构可以帮助他们讨论并做出简化系统的综合决策。

• 持续集成为双方提供了纠正错误的机会，因此，当对方进行一些实验时，对方不会反对。

• 集体所有权使团队能够混合搭配，并使他们保持亲密关系。

因此，您可以成对编写所有代码。另一方面，如果团队是单独工作，则他们更有可能犯错误，过度设计并忽略其他实践。

集体所有权–其他XP实践的支持

集体所有权–劣势

您不可能让所有人在系统中的任何地方进行任何更改。因为，有可能在不知不觉中破坏系统，并且集成成本将急剧上升。

其他XP实践的集体所有权

其他XP实践以以下方式支持集体所有权-

• 持续集成减少了冲突的机会。

• 测试减少了意外破坏事物的机会。

• 使用结对编程，您不太可能破坏代码，并且开发人员可以更快地了解他们可以从中获利的更改。

• 使用编码标准，您将不会在代码上发生冲突。

• 使用重构，您可以使系统保持简单，以便每个人都可以理解。

因此，您可以让任何人在有机会对其进行改进时在系统中的任何地方更改代码。另一方面，在没有集体所有权的情况下，设计的发展速度会大大降低。

持续集成-其他XP实践的支持

持续集成–缺点

工作仅需几个小时，您可能无法集成，因为集成需要很长时间，并且存在太多冲突和偶然破坏某些东西的机会。

与其他XP实践的持续集成

其他XP实践以以下方式支持持续集成-

• 快速测试可以帮助您知道自己没有损坏任何东西。

• 使用结对编程时，要集成的变更流只有一半。

• 通过重构，可以减少碎片，减少冲突的机会。

• 使用编码标准，代码将保持一致。

• 简短的发行版确保了对系统的即时反馈。

• 集体所有权可确保无论谁更改代码和进行集成，都将拥有整个系统的视图。

因此，您可以在几个小时后集成。另一方面，如果您没有快速集成，那么冲突的机会就会增加，集成成本会急剧上升。

40小时工作周–其他XP实践的支持

40小时工作周–缺点

您不可能每周工作40小时。您无法在40小时内创造足够的业务价值。

40小时工作周以及其他XP实践

其他XP实践通过以下方式支持每周40小时-

• 规划游戏为您提供了更有价值的工作。

• 计划游戏和测试的结合确保了您仅需按照自己的想法进行工作。

• 简单的设计和重构使您可以集中精力并按时完成。

• 结对编程可帮助您开展工作，并与伴侣共享其他工作。

• 整个实践可以帮助您以最快的速度发展，因此您无法再走得更快。

因此，您可以在40小时的周内产生足够的业务价值。另一方面，如果团队没有保持新鲜和充满活力，那么他们将无法执行其余的练习。

现场客户–其他XP实践的支持

现场客户–劣势

您不可能在团队中拥有真正的全职客户，不会产生任何价值。他们可以为其他地方的业务创造更大的价值。

具有其他XP实践的现场客户

其他XP惯例通过以下方式为现场客户提供支持。

他们可以为项目创造价值-

• 在规划游戏中，通过为开发人员制定优先级和范围决策。

• 使用隐喻，可以使域中的开发人员更加清晰。

• 在测试中，通过编写验收测试并在每次简短发布后执行验收测试。

因此，他们可以通过为项目做出贡献为组织创造更多价值。

编码标准–其他XP实践的支持

编码标准–缺点

您可能无法要求团队按照通用标准进行编码，因为开发人员通常是个人主义的。

编码标准和其他XP惯例

其他XP惯例通过以下方式支持编码标准-

• 配对编程使它们轻松适应必要的编码标准。

• 持续集成强制他们遵循标准，以便代码一致。

• 集体所有权鼓励他们与标准保持一致，以在必要时和必要时进行更改。