结对编程是否意味着您不需要设计文档？ [关闭]答案

【问题标题】：Does Pair programming mean you don't need design documentation? [closed]结对编程是否意味着您不需要设计文档？ [关闭]
【发布时间】：2010-10-17 19:56:34
【问题描述】：

在结对编程中，团队中每个成员的经验都可以传播给新成员。这种体验总是与代码同步，因为这对“高级”知道代码是如何工作的以及设计是什么。

那么在这种情况下，设计文档的用途是什么？

更新

我不是暗示没有设计，我暗示没有文档。对于一个练习结对编程的团队，我认为每个人都是一次性的，因为每个人都知道代码。如果资深开发者离开，我想总有至少一个人知道代码，因为之前分享过经验。

【问题讨论】：

你是在暗示没有设计还是没有文档？
所以你真正想问什么。文档是理解以前开发人员的编码工作的唯一方法。只要您有良好的文档，您就不需要任何人。因此，每次人们强调文档时，以防万一开发人员离开公司……这有意义吗……
"每个人都是一次性的？"哇，艰难的时期结束了……
也许这个词看起来很难，（英语不是我的母语，我的意思是如果有人离开，项目不受影响）

标签： extreme-programming pair-programming

【解决方案1】：

如果您的团队超过 2 人怎么办？

仅仅因为两个人知道系统的一部分并不意味着它不应该被记录。

我很高兴知道我不必记住系统的每一个微小细节，因为它只存储在我的脑海中。

对于小型系统，这可能有效，但随着系统变大，您会限制自己和同事。我宁愿将内存容量用于新系统，也不愿记住旧系统的所有内容。

【讨论】：

如果您的团队超过两个人，您可以与知道您应该修改/调试/重新思考的代码如何工作的人配对。我认为通过大量结对编程，很多人都知道代码。
考虑一个大型系统，需要多少小时的对等编程来教新人系统如何工作？我建议先让新人读入，而不是在调试/重构的前几天进行结对编程。
如果您的团队由 4（12 和 34）人组成，那么 2 个团队如何知道设计？你需要一个设计，否则你需要更长的启动时间。首先 1 和 2 一起工作，然后 1 和 3 一起工作，2 和 4 一起工作。
我没有大型系统的经验，但我坚信没有人需要知道这个系统的所有代码。只是他完成工作所需的部分。
@Slashene，确实没有人需要知道所有的代码，但在某个地方，知识必须是可检索的。那个地方不可能是其他程序员，至少不是单独的。

【解决方案2】：

你玩过“电话”吗？我认为你不应该用你的代码库来玩它。

【讨论】：

【解决方案3】：

如果高级程序员离开公司/项目怎么办？

【讨论】：

+1：中了彩票，买了一辆宾利，然后带着所有的知识开车离开。
在我工作的一个地方，我的经理坚持要成为所有彩票池的一部分。如果我们都辞职，他不想被困在应对混乱中。

【解决方案4】：

可交付成果集应独立于您是否使用结对编程来决定。

六个月或两年后，所有相关人员可能都在不同的项目（或不同的公司）中。您希望能够回来使用设计文档吗？然后，生产它。如果你不想回来，或者设计很简单，通过规范和代码你可以在没有明确设计文档的帮助下理解它，那么你可以跳过它。

但不要依赖于一年后向你解释设计的两个人。

【讨论】：

【解决方案5】：

维护。你不能指望团队保持静止，因为没有新成员或老成员流失。设计文档确保那些对项目不熟悉、必须维持多年的人能够获得有关已做出的决定、选择该方法的原因以及如何实施的信息。拥有此文档对于项目的长期成功非常重要，可以通过传统文档、源 cmets、单元测试和各种其他方法的组合来提供。

【讨论】：

【解决方案6】：

我不认为结对编程会使设计文档过时。我立即不得不考虑Truck factor。当然，前辈可能知道设计是什么。但是当他生病时会发生什么？当他被卡车撞到时会发生什么？如果他被解雇了怎么办？

结对编程确实可以传播知识，但记录这些知识并没有什么坏处。

【讨论】：

卡车因素我不知道 +1 ;)

【解决方案7】：

谁知道第一个编写的代码？答案是没有人知道，因为它还没有被写出来。之所以没有写出来，是因为没人知道该怎么做，所以需要一份设计文档。

【讨论】：

【解决方案8】：

结对编程只是两个人共用一台计算机。就其本身而言，它并没有说明这对组合使用什么样的设计方法。

结对编程，当作为“Extreme Programming”的一部分时，意味着遵循极限编程指南进行设计。这通常涉及收集和编码“用户故事”。然后这些故事将取代其他设计文档。

【讨论】：

【解决方案9】：

正如您所说，人们的体验可能与代码同步。但设计决策并没有全部记录在代码中——只有所做的选择。

以我的经验，要真正理解为什么代码是这样设计的，你需要了解没有选择的设计选择，尝试过和失败的方法等等。你可以希望“中国人耳语”链正确地传输它，因为代码中没有记录来刷新记忆或纠正错误......

...或者你可以写一些关于设计的文档以及它是如何到达的。这样，您就可以避免将来被维护程序员带入暗巷。

【讨论】：

【解决方案10】：

取决于您所说的“设计文档”。

如果您有功能测试——尤其是行为驱动开发 (BDD) 测试，或者 Fitnesse 或 FIT 测试，那么它们肯定是一种“活动文档”...而且它们肯定有价值以及回归测试。

如果您编写用户故事并将其分解为任务，然后将这些任务写在卡片上让两人一起完成，那么您就是在做某种形式的文档......

这是我在 XP 团队中使用的两种主要形式的文档，它们与所有生产代码配对。

我觉得非常方便的唯一其他文档是半页左右的要点，向人们展示了如何为开发机器设置构建环境。您应该在使用该列表时对其进行维护。

【讨论】：

【解决方案11】：

代码库可能太大，以至于您无法记住您打算实现的每个细节。在这种情况下，参考很有用。

此外，如果您与其他组件等交互，则需要设计。

【讨论】：

【解决方案12】：

如果你想要一个电子表格程序而不是文字处理器，那么设计文档很有用:-)

XP、结对编程、敏捷等等……并不意味着你没有计划，它只是一个远没有那么详细的计划（在微观层面上）正在发生的事情。用户选择的用例更多的是设计，与其他风格的设计/编程相比，它更像是一份活生生的文档。

不要陷入这样的陷阱：因为你正在做一些“酷”的事情，你就不再需要良好的实践——事实上，这种编程风格需要更多的纪律而不是更少的纪律才能成功。

【讨论】：

【解决方案13】：

结对编程是团队避免将大部分项目时间用于记录所有内容的机会。但是对文档的需求取决于你记住重要内容的能力以及你的代码有多好。如果代码难以使用，您可能仍需要大量文档。

你可以尝试一些实验：-

记录几个小部分设计并注意你多久必须参考它。
记录总是很痛苦的东西一起工作。

【讨论】：

【解决方案14】：

否缺少结对编程也不意味着您需要文档。需要文档！ 它的样子可能会让你大吃一惊！

敏捷团队将决定何时以及需要什么文档。一个好的经验法则，如果没有人会读它，就不要写它。不要因为项目经理这么说，就因为提供工件而陷入瀑布式工件思维。

大多数人认为文档是您使用 Word 所做的事情。如果敏捷团队工作正常，则代码本身以及 TDD（测试驱动开发）将有一组自动化测试来记录和执行需求。与代码同步的图像、文档......并且一直保持这种状态。

话虽如此，结对确实有助于在团队中快速传播领域、应用、实践和技能知识。配对还有助于确保团队遵循包括 TDD 和其他自动化测试在内的工程实践。结果是应用程序保持健康，并且很容易带来未来的变化。

因此，归根结底，结对编程会产生更好的文档。它不会消除文档（尽管您可能无法找到 Word 文档）。

【讨论】：

【解决方案15】：

我是一名拥护者和文档爱好者。结对编程不需要“一位高级开发人员”。根据我的结对编程经验，所有级别的开发人员都结对在一起，以实现快速开发。有很多次我与初级开发人员一起工作，并且会在键盘上进行权衡。有很多次我与高级架构师一起工作，并且会在键盘上进行权衡。文档仍然是必要的，尤其是您的核心组件和数据库。

【讨论】：

【解决方案16】：

结对编程仅支持您的编码和逻辑方面。

但是文档是很好的做法。总是做文档...

【讨论】：

您可以分发任务，一个人会思考和记录。其他人可以编码......它对你有用吗？？？？