极限编程 - 支持性实践
如果孤立地实施极限编程实践，可能会很薄弱，从而导致失败。在极限编程中，所有实践都需要作为一个整体来考虑，以便它们相互支持。一个实践的弱点会被其他实践的优势所弥补。
在本章中，我们将重点关注每种实践如果孤立实施可能存在的弱点。我们将了解极限编程如何在与其他实践结合使用时支持这种实践克服弱点。
计划游戏 – 来自其他 XP 实践的支持
在本节中，我们将了解计划游戏的弱点以及其他 XP 实践如何支持它。
计划游戏 – 缺点
计划游戏的缺点是，您不可能仅凭一个粗略的计划就开始开发，并且您不能不断更新计划，因为这会花费太长时间并让客户感到不安。
计划游戏与其他 XP 实践
其他 XP 实践以以下方式支持计划游戏：
在计划游戏中，客户也参与更新计划，基于开发人员提供的估算。
您进行短周期发布，以便计划中的任何错误最多只会产生几周或几个月的影响。
您的客户与团队一起工作，因此他们可以快速发现潜在的变化和改进机会（在线客户）。
持续测试帮助开发人员和客户确定立即需要什么。
因此，您可以从一个简单的计划开始开发，并在进行过程中不断完善它。
短周期发布 – 来自其他 XP 实践的支持
短周期发布 – 缺点
您不可能在几个月后投入生产。您当然不可能以每天到每隔几个月为周期的频率发布新系统版本。这是因为您需要时间来吸收新的需求，并将更改整合到当前代码中。
短周期发布与其他 XP 实践。
其他 XP 实践以以下方式支持短周期发布：
计划游戏帮助您处理最有价值的故事，因此即使是一个小型系统也会具有业务价值。
持续集成使打包发布的成本降到最低。
测试将缺陷率降低到足以使发布前不需要冗长的测试周期的程度。
您可以进行简单的设计，足以满足本次发布的需求，而不是永远都适用。
因此，您可以在开发开始后不久就进行短周期发布。
隐喻 – 来自其他 XP 实践的支持
您不可能仅仅依靠一个隐喻就开始开发。它可能缺乏足够的细节，而且您可能是错的。
隐喻与其他 XP 实践
其他 XP 实践以以下方式支持隐喻：
通过结对编程，您将从已实现的代码和测试中获得快速具体的反馈，了解隐喻是否正常工作。
您的现场客户可以轻松地使用隐喻来谈论系统。
持续重构允许您改进您对隐喻在实现中含义的理解。
简单设计帮助您与隐喻建立映射。
因此，您可以仅仅依靠一个隐喻就开始开发。
简单设计 – 来自其他 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实践以以下方式支持代码规范：
结对编程使他们能够轻松地适应必要的代码规范。
持续集成强制他们遵循标准，以便代码保持一致。
集体代码所有权鼓励他们与标准保持一致，以便在任何需要的时候进行更改。