与数量奇数的团队成员结对编程？ [关闭]答案

【问题标题】：Pair Programming with an uneven number of team members? [closed]与数量奇数的团队成员结对编程？ [关闭]
【发布时间】：2009-07-12 12:46:04
【问题描述】：

最近，我们在工作中遇到了一个问题，如果一个人自己编写一些代码，似乎其他团队成员看着它就会出现“嗯？这很难看，难以管理，我需要重写”

事实上，最近，我自己不得不重构前一周写的东西，以便能够添加到我的（相关）功能中。

我知道结对编程是实现这一目标的方法，但我们的团队参差不齐（3 名成员）。由于我们的团队目前正面临着相当大的压力，我们真的没有时间进行同行评审（尽管我们可以进行结对编程，因为我们可以将其估算到我们的任务估算中）

我只是很好奇人们会建议我们如何通过生成糟糕的代码来克服这些问题。

【问题讨论】：

这是一个关于结对编程的有趣链接：cafe.elharo.com/programming/why-pair-programming-works

标签： agile scrum pair-programming

【解决方案1】：

当您独自工作并编写了您的同事认为丑陋且难以管理且需要重写的代码时，您会：

(a) 当你再看一遍时同意他们，

(b) 不同意？

如果是 (a)，那么问题在于您自己在编写代码时并没有完全阐明代码。由于结对编程是唯一能让你写出体面代码的东西，我想我建议“奇数”应该用于不涉及编写大量糟糕代码的任务：bug-hunting；也许编写测试代码，因为这往往不那么可怕。同时，努力提高编写更好代码的技能——也许对几个月前自己的代码进行审查，并记录其中的问题。

如果 (b)，那么您遇到的问题是表达您的想法的方式不兼容。按照您的标准，该代码可能还不错，但它是相互无法理解的，这在公司环境中意味着它是糟糕的代码。结对编程意味着你写的东西是一种妥协，三分之二的人都理解，但这并不是真正的解决方案。你需要就彼此的代码最困难的地方达成一些共识，并停止这样做。你们都迫切需要从“我的 2 位同事会喜欢这个代码”而不是“我喜欢这个代码”的角度来考虑“代码质量”。

无论哪种方式，你们都需要编写代码为了被阅读，而不是为了尽快完成当前的工作。就我个人而言，我通过尝试以我认为其他人可能表达和理解的方式表达事物来做到这一点，而不仅仅是当时对我有意义的方式。最终会成为习惯。当我写代码时，我是为公众写的，就像我为公众写这篇文章一样。好的，所以在我的个人项目中，是一群和我一样思考的人，而在工作中，是一群像我的同事一样思考的人。但原则是编写代码，就好像有人在阅读它一样。您是在向他们解释自己，而不是编译器。

并不是说我的代码是世界上最好的，但我确实认为我受益于我的第一份工作是在一家拥有 30 多名程序员的公司中，所以我看到了各种各样的思考方式。还有一些“不该做什么”的例子，其中一个程序员做了一些没有人容易理解的事情，因此可以明确地说是坏事。只有 3 人，尚不清楚 2 对 1 的意见分歧是否意味着 1 是怪胎或合理的少数。当我做了一件事，4 或 5 个人可以看到它并立即说“哎呀，不要那样做”，然后我开始真的相信这只是一个愚蠢的想法。

我还建议，如果不允许您为代码审查预算，那就撒谎和作弊。如果你在大量重写别人的代码，你实际上是在花时间去审查它，你只是没有提供反馈，这是代码审查中有价值的部分。因此，悄悄地进行审查 - 编写一个或三个函数，然后让同事查看它并就它是否对他们有意义给你即时反馈。完成后立即与监视器上的代码进行对话会有所帮助，但不要在人们“心流”时打断他们，或陷入冗长的争论。这不是结对编程，也不是正式的代码审查，但它可能会帮助你弄清楚你自己在做什么，这太糟糕了。

【讨论】：

【解决方案2】：

我很惊讶您没有时间进行同行评审，但您有时间进行配对编程。后者不是更浪费时间吗？

我们公司也只有三名开发人员，而且，令人惊讶的是，我们目前正面临着巨大的压力。我很确定如果我建议结对编程，我的老板会嘲笑我，因为这将被视为一项任务的工时数量增加了一倍，即使实际上这不是它应该产生的结果。我们的同行评审从不超过一个小时，这是一个极端情况。平均而言，我会说它们大约需要 10 分钟，并且每个开发人员一天只发生一两次。

IMO 你应该试试同行评议。您经常会发现违规的人（即编写质量较低的代码的人）最终意识到他们需要付出更多的努力，并且质量会随着时间的推移而提高。

【讨论】：

你不需要在同行评议中得罪人。
当他说“冒犯的人”时，他指的是犯错的人，而不是有人被冒犯了。
@troubadour：结对编程绝不是浪费时间。当一个人键入代码时，另一个人已经在考虑下一步要执行的过程，如果它适合解决方案的其余部分，则正在编程。结对编程看似浪费时间，但实际上结对编写的代码更稳定，更适合整个应用程序。
@罗伯特。谢谢，这很有意义，我当然相信你的代码会更稳定，从而节省修复缺陷的时间——时间总是被低估的。这是我想在某个时候尝试的东西，但正如我所说，我不知道我的公司目前是否会这样做。
结对编程对我们来说很多时候会加快速度，因为共享知识（“哦，你在这里做”而不是在代码中寻找一些你需要的随机位改变)

【解决方案3】：

如果您有 3 个开发人员并且每个人都认为其他人的代码不好，那么您迫切需要同行评审。

【讨论】：

可能会被锁在一个房间里，直到你们都同意自己的代码无法理解...

【解决方案4】：

所以：

你被逼得很厉害
你的代码质量很差

你认为这两者可能相关吗？答案是修复时间表。

【讨论】：

我们的代码似乎只会在某些特殊情况下变得很糟糕，而且只有当我们有一个开发人员在处理它时。
假设结对编程更有效率，那么如果一个人在日程安排不合理时可能会感到更大的压力，从而比在非结对环境中犯的错误更多。跨度>

【解决方案5】：

一次将所有三个配对。

设置一些编码标准。

为破坏构建的开发人员使用愚蠢的上限。

召开每日站立会议以交流进展情况。

还可以每周尝试两次同行评审，例如周二和周五。

【讨论】：

【解决方案6】：

结对编程不必每天整天都在有效。每周一起工作一两个小时，我就看到了很好的结果。一种方法是先将 A 和 B 配对一段时间，然后再配对 A 和 C，然后再配对 A 和 B ......中间有很多单独的时间。

这也很大程度上取决于团队成员的个性和化学反应。这三个中的两个可能会非常好地协同工作，您会希望从中受益。

【讨论】：

^ 我完全同意，尤其是这个答案的第一部分！

【解决方案7】：

你仍然应该配对。设置会话，说每周 1 天，并轮换成对。这应该让你的经理开心，提高代码质量，改善沟通。如果您保留有关配对和单独编码中发生多少错误的指标，您应该开始看到好处并将其显示给您的经理，

例如，这花费了 x 个工时，但平均节省了 y 个缺陷修复。此外，clode 更清洁，并且比我们下次触摸它所需的时间更短。

从那里您将获得硬统计数据，您可以开始编写更多代码。

基本上你的故事似乎和我的一样。

没时间做事。
出错了。
赶紧修复它（需要更多时间）
转到 1

你需要停止腐烂。

【讨论】：

【解决方案8】：

代码审查
启用 Stylecop，强制您编写可读、标准化和可管理的代码

【讨论】：

1 > 2. 我见过很多不可读的代码通过了样式指南，但没有多少不可读的代码通过了代码审查（除了那些作者和审查者一直生活的情况在同一个掩体中，并制定了他们自己的一套私人假设）。

【解决方案9】：

我们使用代码审查。此外还有一些单一的任务：更改图表，安装一些东西......

【讨论】：