在结对编程中,团队中每个成员的经验都可以传播给新成员。这种体验总是与代码同步,因为对的“高级”知道代码是如何工作的以及设计是什么。
那么在这种情况下设计文档的效用是什么?
更新
我并不暗示没有设计,我暗示没有文件。 有一个练习结对编程的团队,我认为每个人都是一次性的,因为每个人都知道代码。如果高级开发人员离开,我认为至少有一个人知道代码,因为之前已经分享过这段经历。
答案 0 :(得分:12)
如果您的团队人数超过2人怎么办?
仅仅因为两个人知道系统的一部分并不意味着它不应该被记录下来。
我很高兴知道我不必记住系统的每一个微小细节,只因为它存储在其他地方而不是在我脑海中。
对于小型系统,这可能有效,但随着系统变大,限制自己和同事。我宁愿将内存容量用于新系统而不是记住旧系统的所有内容。
答案 1 :(得分:4)
你玩过“电话吗?”我不认为你应该用你的代码库来玩它。
答案 2 :(得分:4)
如果高级程序员离开公司/项目怎么办?
答案 3 :(得分:4)
可交付成果应该独立于是否使用结对编程来决定。
六个月或两年后,所涉及的所有人都可以在不同的项目(或不同的公司)。您是否希望能够返回并使用设计文档?然后,生产它。如果你不想回来,或者设计很简单,你可以在没有明确设计文件的情况下通过规范和代码理解它,那么你可以跳过它。
但是一年之后不要依赖两个人向你解释设计。
答案 4 :(得分:3)
维护。你不能指望团队保持静止,因为没有新成员或失去旧成员。设计文档确保那些不熟悉项目的人员需要多年来维护项目,他们可以获得有关决策的信息,选择方法的原因以及实施方法。对于项目的长期成功而言,拥有此文档非常重要,可以通过传统文档,源注释,单元测试和各种其他方法的组合来提供。
答案 5 :(得分:2)
我没有看到结对编程使设计文档过时。我立刻要考虑Truck factor。当然,老年人可能知道设计是什么。但是当他生病时会发生什么?当他被卡车撞击时会发生什么?如果被解雇怎么办?
结对编程确实传播知识,但记录这些知识永远不会伤害。
答案 6 :(得分:1)
谁知道第一次编写代码?答案是没有人知道,因为它还没有写。它没有被写入的原因是因为没有人知道该怎么做,因此需要一个设计文档。
答案 7 :(得分:1)
结对编程只有两个人共享一台计算机。就其本身而言,它没有说明这对使用何种设计方法。
结对编程,当作为“Extreme Programming”的一部分时,意味着遵循极限编程指南进行设计。这通常涉及收集和编码“用户故事”。这些故事将取代其他设计文档。
答案 8 :(得分:1)
正如您所说,人们的体验可能与代码同步。但是设计决策并不是全部都在代码中捕获 - 只有选择权才有。
根据我的经验,要真正理解为什么代码的设计方式如此,您需要了解未选择的设计选择,尝试过的方法和失败等等。您可以希望“中国人低语”鉴于代码中没有记录这一点来刷新存储器或纠正错误,链正确地传输了这个......
...或者你可以写一些关于设计及其如何到达的文档。这样,您将来可以避免被维护程序员带入黑暗小巷。
答案 9 :(得分:1)
取决于“设计文档”的含义。
如果您有功能测试 - 特别是行为驱动开发(BDD)测试,或Fitnesse或FIT测试,那么它们肯定是“活动文档”的形式 ......他们肯定有价值以及回归测试。
如果您编写用户故事并将其分解为任务并将这些任务写在卡片上以进行配对那么您正在做一种形式的文档......
这些是我在XP团队中使用的两种主要形式的文档,它们在所有生产代码上配对。
我发现的另一个非常方便的其他文档是一个半页左右的项目符号,显示人们如何为开发机器设置构建环境。你应该在使用它时保持列表。
答案 10 :(得分:0)
代码库可能非常大,您无法人为地记住您打算实现的每个细节。在这种情况下,引用很有用。
此外,如果您正在与其他组件等进行交互,则需要进行设计。
答案 11 :(得分:0)
配对编程仅支持您的编码和逻辑方面。
但文档是一种很好的做法。总是做文件......
答案 12 :(得分:0)
如果您想要一个电子表格程序而不是文字处理程序,那么设计文档可能会有用: - )
XP,对编程,敏捷等等......并不意味着你没有计划,它只是一个远不那么详细的计划(在微观层面)正在发生的事情。用户选择的用例更多的是设计,与其他设计/编程风格相比,它更像是一个活文档。不要陷入陷阱,因为你做了一些“酷”的事情,你不再需要良好的实践 - 事实上,这种编程风格需要更多的纪律而不是更少的成功。
答案 13 :(得分:0)
结对编程是团队避免不得不花费大部分项目时间来记录所有内容的机会。但是对文档的需求取决于你在记住重要内容以及代码有多好的方面有多好。如果代码难以使用,您可能仍需要大量文档。
您可以尝试一些实验: -
答案 14 :(得分:0)
否缺少配对编程也意味着您需要文档。需要文档! 看起来可能会让您感到惊讶!
敏捷团队将决定何时需要哪些文档。一个好的经验法则,如果没有人会读它,就不要写它。不要因提供工件而陷入瀑布工件中,因为项目经理这样说。
大多数人认为文档是用Word做的。如果敏捷团队正常工作,那么使用TDD(测试驱动开发)的代码本身将具有一组自动化测试,用于记录和实施要求。图像,与代码同步的文档......并且它保持这种状态。
话虽如此,配对确实可以帮助领域,应用,实践和技能知识迅速传播到团队中。配对还有助于确保团队遵循包括TDD和其他自动化测试在内的工程实践。结果是应用程序保持健康,未来的变化很容易实现。
因此,底线,结对编程可以产生更好的文档。它不会消除文档(尽管您可能无法找到Word文档)。
答案 15 :(得分:0)
我是支持者,也是文档的粉丝。结对编程不需要“一个高级开发人员”。根据我对结对编程的经验,所有级别的开发人员都配对在一起,以便快速开发。我曾多次与初级开发人员合作,并会在键盘上进行权衡。我曾多次与高级建筑师合作,并会在键盘上进行权衡。仍然需要文档,尤其是核心组件和数据库。