极限编程——支持实践

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

在本章中，我们将重点讨论每种实践如果单独实施可能存在的弱点。我们将看到极限编程如何支持这种实践，以克服与其他实践结合实施时的弱点。

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

在本节中，我们将了解规划游戏的弱点以及其他 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 实践通过以下方式支持现场客户。

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

在规划游戏中，通过为开发人员做出优先级和范围决策。
使用 Metaphor，为该领域的开发人员带来清晰度。
在测试中，通过编写验收测试并在每次简短发布后执行验收测试。

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

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

编码标准 – 缺点

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

编码标准与其他 XP 实践

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

结对编程使他们能够轻松适应必要的编码标准。
持续集成强制他们遵循标准，以便代码保持一致。
集体所有制鼓励他们遵守标准，以便在必要时随时随地进行更改。