在结对编程中，团队中每个成员的经验都可以传播给新成员。这种体验总是与代码同步，因为这对“高级”知道代码是如何工作的以及设计是什么。
那么在这种情况下，设计文档的用途是什么？
更新
我不是暗示没有设计，我暗示没有文档。对于一个练习结对编程的团队，我认为每个人都是一次性的，因为每个人都知道代码。如果资深开发者离开，我想总有至少一个人懂代码，因为之前分享过经验。
问问题
550 次
16 回答
12
如果您的团队超过 2 人怎么办？
仅仅因为两个人知道系统的一部分并不意味着它不应该被记录在案。
我很高兴知道我不必记住系统的每一个微小细节，因为它只存储在我的脑海中。
对于小型系统，这可能有效，但随着系统变大，您会限制自己和同事。我宁愿将内存容量用于新系统，也不愿记住旧系统的所有内容。
于 2009-04-06T14:42:09.477 回答
4
你玩过“电话”吗？我认为你不应该用你的代码库来玩它。
于 2009-04-06T14:43:34.157 回答
4
如果高级程序员离开公司/项目怎么办？
于 2009-04-06T14:43:36.870 回答
4
应独立于您是否使用结对编程来决定可交付成果的集合。
六个月或两年后，所有参与的人都可能在不同的项目（或不同的公司）中。您希望能够回来使用设计文档吗？然后，生产它。如果你不想回来，或者设计很简单，通过规范和代码你可以在没有明确设计文档的帮助下理解它，那么你可以跳过它。
但不要依赖一年后两个人向你解释设计。
于 2009-04-06T14:45:16.727 回答
3
维护。你不能指望团队保持静止，因为没有新成员或老成员流失。设计文档确保那些对项目不熟悉、必须维持多年的人能够获得有关已做出的决定、选择该方法的原因以及如何实施的信息。拥有此文档对于项目的长期成功非常重要，可以通过传统文档、源注释、单元测试和各种其他方法的组合来提供。
于 2009-04-06T14:44:32.063 回答
2
我不认为结对编程会使设计文档过时。我立即不得不考虑卡车因素。当然，前辈可能知道设计是什么。但是当他生病时会发生什么？当他被卡车撞到时会发生什么？如果他被解雇了怎么办？
结对编程确实传播了知识，但记录这些知识永远不会有坏处。
于 2009-04-06T14:45:18.363 回答
1
谁知道第一个编写的代码？答案是没有人知道，因为它还没有被写出来。之所以没有写出来，是因为没有人知道该怎么做，因此需要一份设计文档。
于 2009-04-06T14:43:05.670 回答
1
正如你所说，人们的体验可能与代码同步。但是设计决策并没有全部记录在代码中——只有所做的选择在那里。
以我的经验，要真正理解为什么代码是这样设计的，您需要了解未选择的设计选择、尝试过和失败的方法等。您可以希望“中国耳语”链传达这一点正确，因为代码中没有记录来刷新内存或纠正错误......
...或者你可以写一些关于设计的文档以及它是如何到达的。这样，您就可以避免将来被维护程序员带入黑暗的小巷。
于 2009-04-06T14:48:42.927 回答
1
取决于您所说的“设计文档”是什么意思。
如果您有功能测试——尤其是行为驱动开发 (BDD) 测试，或者 Fitnesse 或 FIT 测试，那么它们肯定是“活动文档”的一种形式……它们肯定具有价值以及回归测试。
如果您编写用户故事并将它们分解为任务并将这些任务写在卡片上以供成对完成，那么您就是在做一种文档形式...
这是我在 XP 团队中使用的两种主要形式的文档，它们与所有生产代码配对。
我觉得非常方便的唯一其他文档是半页左右的项目符号集，向人们展示了如何为开发机器设置构建环境。您应该在使用它时维护该列表。
于 2009-12-11T14:55:23.520 回答
0
代码库可能太大了，以至于您无法记住您打算实现的每个细节。在这种情况下，参考很有用。
此外，如果您正在与其他组件等交互，您需要一个设计。
于 2009-04-06T14:44:10.317 回答
0
结对编程仅启用您的编码和逻辑方面。
但是文档是很好的做法。总是做文档...
于 2009-04-06T14:45:10.580 回答
0
好吧，如果您想要一个电子表格程序而不是文字处理器，那么设计文档很有用:-)
XP、结对编程、敏捷等......并不意味着你没有计划，它只是一个远没有那么详细的计划（在微观层面上）正在发生的事情。用户选择的用例更多是设计，与其他风格的设计/编程相比，它更像是一个活文档。
不要陷入这样的陷阱：因为您正在做一些“酷”的事情而不再需要良好的实践——事实上，这种编程风格需要更多的纪律而不是更少的纪律才能成功。
于 2009-04-06T14:45:52.980 回答
0
不没有结对编程也不意味着您需要文档。需要文档！它的样子可能会让你大吃一惊！
敏捷团队将决定何时以及需要什么文档。一个好的经验法则，如果没有人会读它，就不要写它。不要因为项目经理这样说，就因为提供工件而陷入瀑布式工件思维。
大多数人认为文档是您使用 Word 执行的操作。如果敏捷团队工作正常，则代码本身以及 TDD（测试驱动开发）将有一组自动化测试来记录和执行需求。图像、与代码同步的文档……并且一直保持这种状态。
话虽如此，结对确实有助于在团队中快速传播领域、应用、实践和技能知识。配对还有助于确保团队遵循工程实践，包括 TDD 和其他自动化测试。结果是应用程序保持健康并且很容易带来未来的变化。
因此，最重要的是，结对编程会产生更好的文档。它不会消除文档（尽管您可能无法找到 Word 文档）。
于 2009-05-17T23:26:46.303 回答
0
我是一名拥护者和文档爱好者。结对编程不需要“一位高级开发人员”。根据我的结对编程经验，所有级别的开发人员都结对在一起，以实现快速开发。有很多次我与初级开发人员一起工作，并且会在键盘上进行权衡。有很多次我与高级架构师一起工作，并且会在键盘上进行权衡。文档仍然是必要的，尤其是您的核心组件和数据库。
于 2009-05-27T15:00:27.630 回答
0
结对编程是团队避免将大部分项目时间用于记录所有内容的机会。但是对文档的需求取决于你记住重要内容的能力以及你的代码有多好。如果代码难以使用，您可能仍需要大量文档。
您可以尝试一些实验：-
- 记录设计的几个小部分，并注意您必须多久参考一次。
- 记录那些总是很难处理的东西。
于 2009-04-17T15:39:59.093 回答