极限编程 - 支持实践
如果孤立地实施极限编程实践，可能会很弱，因此可能会失败。在极限编程中，所有实践都需要作为一个整体来考虑，以便它们相互支持。一个实践的弱点被其他实践的优势所掩盖。
在本章中，我们将重点介绍如果孤立地实施每个实践可能存在的弱点。我们将看到极限编程如何支持这种实践，以克服与其他实践结合实施时的弱点。
规划游戏 - 其他 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 实践通过以下方式支持现场客户。
他们可以为项目创造价值 −
在 Planning Game 中，通过为开发人员制定优先级和范围决策。
使用 Metaphor，为开发人员提供领域清晰度。
在测试中，通过编写验收测试并在每次短期发布后执行验收测试。
因此，他们可以通过为项目做出贡献为组织创造更多价值。
编码标准 - 其他 XP 实践的支持
编码标准 - 缺点
您不可能要求团队按照通用标准进行编码，因为开发人员通常个人主义。
编码标准与其他 XP 实践
其他 XP 实践以以下方式支持编码标准 −
结对编程使它们能够轻松适应必要的编码标准。
持续集成强制它们遵循标准，以便代码保持一致。
集体所有权鼓励他们遵守标准，以便在必要时随时随地进行更改。
