敏捷中的结对编程要求我们将支付给单个程序员的薪水增加一倍。当然，使用这种方法，代码的质量要好得多，bug 会更早发现等等，但这仍然值得那笔钱吗？也许我们应该把第二个开发者的薪水付给少数测试员（后者通常比合格的程序员便宜得多）？有没有人有这种比较的经验？
Henryk Konsek
问问题
6212 次
21 回答
55
你怎么知道你的未配对程序员更有效率？有时我觉得单/双可以媲美兔子和乌龟的古老童话。
结对并不会变成适得其反的工作。我不知道有多少次我看到开发人员花费数周时间来开发后来被更简单的东西所取代的东西。“在区域内”的单一程序员经常做愚蠢的事情。当您想要用更少的代码获得更多的冲击力时，生成太多的代码太容易了。
而在后人中，当尘埃落定时，你会发现成百上千行代码，因为有人不了解库 X 或技术 Y ，所以可能没有编写。配对改善了这个问题，但并没有消除它。它鼓励个人和两人在陷入盲目的代码兴奋之前做更多的研究。
我希望我能够配对更多......
于 2009-03-20T22:03:16.520 回答
18
我们在我们的公司中使用这种方法，但仅用于困难的任务，或者当您不确定其他人已经完成的工作时，我认为这些工作非常有效。它可以避免您陷入困境，并能够在必要时从人们那里获得想法，同时仍然能够独立地完成大多数简单的任务。
我也相信它比代码审查更有益，这是我们在我工作的地方所做的其他事情。在没有提供重要上下文的情况下，通常很难在进行代码审查时完全了解发生了什么，此时您并不总是有时间考虑所有的进出。结对编程从一开始就为您提供了上下文，并允许您花更多时间思考可能会或可能不会导致问题的边缘情况。
于 2009-03-20T21:59:25.377 回答
15
尽管我同意迄今为止关于结对编程是一件好事的大多数回应，但我会扮演魔鬼的拥护者并争辩说它并不总是有意义的。
当你配对时，你不会得到一个拥有两倍大脑的程序员。你会得到一个程序员，它是你们两个大脑的结合。所以基本上任何时候我搞砸了，我的搭档抓住或找到更好的方法，这是一个加号。但是，任何时候我自己编写正确的代码都是浪费钱，因为不需要我的合作伙伴。
基本上，您需要评估您正在处理的代码。简单的任务通常不值得花钱请人坐在肩膀上并确保你正确地编写了你的 for 循环。然而，在某个阈值上，这些任务足够复杂，以至于结对编程的投资回报率是合理的。
于 2009-03-20T22:30:20.230 回答
13
通过结对编程，您可以结合：
- 更高质量的代码
- 更好地分布内部知识
- 更有团队精神
你不会比这更容易获得那么多的投资回报。
再说一次，您不应该将它用于所有任务。
于 2009-03-20T22:20:16.137 回答
12
如果花费的时间少于使用一个开发人员所花费的时间的 1/2，这并不意味着成本会增加一倍。我认为这对困难或低级任务会有所帮助。我发现这是值得的，因为有人会说“不，不要那样做！” 早在它最终出现在生产代码中之前，它真的会花费你的时间和金钱。
我写过操作系统和类似性质的东西，有人坐在我旁边仔细检查我的逻辑是非常宝贵的。
于 2009-03-20T21:59:54.097 回答
9
在工作中，我们一直使用结对编程。诀窍是要知道哪些任务应该成对完成，如果由两个开发人员完成，那将是“浪费时间”。经验法则是更面向研究的任务（即 POC 和尖峰）应该成对完成，同时开发新功能（这样知识就会存在于不止一个头脑中）。更普通的任务，例如 CI 服务器安装或替换插件图标，由单个开发人员完成。另一个因素是团队成员的当前可用性以及该迭代中要完成的当前任务。
于 2009-03-20T22:07:05.670 回答
9
很难说——我花了很多时间在强制配对环境和配对可选环境中工作。我见过的最高质量的代码不在配对环境中。这可能更多地与各个开发人员的能力和纪律有关。有时你会从配对中得到你的钱，特别是在一些编码器不是顶级的情况下。但是，如果所有编码员都是经验丰富、训练有素的编码员，那么如果他们一直在配对，那你就是在浪费你的钱。
我曾多次经历的一种经历对我的编码学科和我生产的产品质量产生了巨大影响：携带寻呼机。当我必须支持我编写代码的系统时，它会改变我编写代码的方式。也就是说，我以这样一种方式编码，以防止该寻呼机关闭。结果是质量更好的产品，通常也有更好的代码质量。我见过的从未携带寻呼机的编码器产生的代码更脆弱。在他们得到支持之前，他们甚至无法理解和改进。
于 2009-04-30T17:52:29.700 回答
7
越早发现错误/缺陷，修复的成本就越低，因此使用这笔钱雇佣更多的 QA 人员而不是其他开发人员，将花费你更多的时间/金钱，因为从 DEV 到 QA 的旅行次数。
话虽如此，结对编程并不适合每个人，一些开发人员不能很好地结对，他们会分散对方的注意力，把所有的时间都花在打架上等等。
如果您有可以结对编程的开发人员，从长远来看，当您添加更多可维护的代码、减少缺陷从而减少 QA 时间，以及最重要的是，如果其中一位开发人员被公共汽车撞到，从长远来看，这可能会更有益不必等待某人加快项目进度，然后才能完成更多工作。
如果您的开发人员无法配对程序，请不要强迫他们加入，您要做的就是浪费时间和金钱。
于 2009-03-20T22:16:13.540 回答
7
不，你没有。每个程序员仍然只能得到一份薪水。
如果您不将其称为“结对编程”，您是否认为您的程序员不会互相交谈？你认为编程是完全可并行化的吗？
于 2009-03-20T23:12:16.497 回答
7
结对编程可以非常有效，但是您不应该结对雇用程序员。您不能强迫开发人员配对程序。只有当两个开发人员点击并决定他们可以互相学习并一起构建一些很棒的东西时，它才有效。我的建议是聘请尽可能多的最聪明的开发人员，并将他们安置在自然而然地鼓励兼职结对编程的环境中。开发人员需要能够单独编写代码，还需要与团队中的其他人讨论它。
找到适合您和您的公司的正确组合将更像是一门艺术而不是科学，当然不是盲目地遵循某些已发布方法的要求就可以做到的事情。
也就是说，在它们被检入之前，你压制的错误越多，从长远来看，你节省的越多。让另一个开发人员在您构建某些东西时进行观察总是比之后让测试人员黑箱更有效。我会称之为钱花得值。
于 2009-03-21T20:17:47.843 回答
5
结对编程的第一个假设是故事卡的开发成本是其两倍。假设是错误的。这是为什么？
- 提高质量：一对活跃的程序员在同一张故事卡上工作，完成卡时缺陷更少
- 提高生产力：在解决问题时，如果没有完全阻塞，则一对不太可能放慢速度。此外，当您与合作伙伴一起工作时，更难通过电子邮件或网络度假……您不想让合作伙伴失望。成对工作时，您将通过更简洁的设计和更少的代码行来解决问题
- 消除知识孤岛：通过轮换对，您将在整个团队中学习应用程序和领域业务知识。该团队不太可能被阻止，因为 Sue 在度假时没有其他人知道她的代码。
- 知识转移：当他们一起工作时，轮换的人会互相传授新的技能（工程和领域）。每个人的团队水平都会提高，知识会通过团队传播。
- 团队自我选择：团队学习一个花药的技能，并迅速淘汰表现不佳的人。
根据实际经验，我们已经看到缺陷显着下降。可以在不减慢团队速度的情况下添加新团队成员（尝试使用非配对团队）。在一次试验中，一个团队估计了一组故事卡的工作，就好像六个单独的开发人员将分别完成代码一样。然后让六位开发人员配对。他们按时高质量地完成了工作。如果您不配对，您将花费大量时间来交付低质量的产品，您无法扩展，并且您拥有太多的专业知识孤岛。
在第二个示例中，我们估计要在要求的时间内完成工作，我们需要将一个团队从 4 对增加到 7 对。我们给了自己 1 个月的时间来加入新的配对。我们将一位新开发人员与一位经验丰富的开发人员配对，并在故事卡中轮换配对。团队在计划的时间内按质量完成了所有可交付成果。如果没有配对，就不可能将 6 名开发人员添加到 8 名开发人员的团队中并达到目标！
最重要的是，您将通过配对节省资金。您将花费大约相同的时间，以更高的质量交付，提高团队的绩效、技能和知识，并清除死木。您的节省将伴随着可持续的步伐和显着减少拖慢团队速度的缺陷。
于 2009-05-01T19:45:25.863 回答
4
结对编程不会使成本加倍——它只是将打字量减半。打字不是编程。完成软件中的功能就是编程。是解决问题。你不能只用输入的代码行来衡量它。一些程序员会使用更好的算法，因此他们最终会减少打字。
您如何定义物有所值？从开始编码到完成实时工作功能之间可能经过的总时间？
不配对的成本通常不会被正确计算：问题是大多数人没有衡量缺陷的数量或修复最初没有正确完成的工作所花费的额外时间——他们只是衡量首先是“把工作扔过栅栏”所花费的时间。
在配对时有一些衡量生产力的尝试，但不幸的是，它有点与“交付的代码行数”联系在一起——这是一个虚假的指标。
您可能会发现这项研究相关： http ://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
于 2009-10-29T21:27:43.800 回答
3
前提是您的生产力翻倍以上。部分收益立即实现（例如，在签入代码之前），部分收益在错误和故障较少时进一步实现。
当我教有两个学期经验的学生时，对于大多数配对来说，他们的生产力翻了一番以上，因为他们互相提问，他们学习和完成的速度更快。但这并不是普遍正确的。一对不匹配的对可能需要更长的时间，并且比技术更熟练的一半做得更差。
于 2009-03-20T22:44:04.550 回答
3
其他许多行业的质量管理经验告诉我们，从长远来看，缺陷预防比缺陷检测（也称为 QA）和后续修复更便宜。
他们还了解到，大多数情况下的长期范围为 1 到 2 年，这意味着您的投资在此之后会得到回报。考虑到这种规模的投资通常预计在 4 年后达到收支平衡，这非常好！
问题在于，其他行业花了几十年的时间积累了足够的数据来证明他们的情况。你可以很容易地找到数据来支持他们的结论，并以此类比为软件得出结论，但截至今天，还没有软件业务的证据。
话虽如此，我相信类似的结论是有效的：一对开发人员和一个测试人员比一个开发人员和两个测试人员更有效率。
如果您在向管理层证明坐在一台计算机前的两名昂贵的开发人员有问题时，还有许多其他有助于预防缺陷的事情，但对管理层来说并不那么明显（因此令人恼火）。
于 2009-03-25T16:54:22.027 回答
3
当我在朋友的船上编程时，我们并不总是有时间，因为我们中的一个人在航行，而另一个人在编码。但是，当我们锚定或在平静的水中时，我们可以进行结对编程并且效果很好。
于 2009-05-01T19:49:33.047 回答
2
没门！在我工作的公司中，我们练习了很多结对编程！它可以非常快速且非常有效地完成工作！试一试！你稍后会评估它！
于 2009-04-30T16:52:31.403 回答
2
来自北卡罗来纳州的 Laurie Williams 教授是学术界关于结对编程有效性的主要权威，她对此进行了大量研究。
如果您想要“官方词”，请访问她的出版物列表。
她的文章：“加强结对编程的案例”非常有名。
于 2009-04-30T17:19:39.780 回答
2
这取决于开发人员。不幸的是，您不能仅仅将任何两个开发人员粘在一起并期望及时、高质量的结果。不是每个人都适合配对编程，甚至不适合在敏捷开发环境中工作。关于配对编程，我认为值得的两件事是：（1）开发人员之间的交叉培训；(2) 实时同行评审。交叉培训将有助于加强整个团队的技能，实时同行评审可以消除对正式同行评审的需要。这些年来，我从同龄人那里学到的东西比我在技术培训中学到的还要多。
于 2009-04-30T17:39:01.603 回答
1
除非您是一家很小的商店，否则您可能已经支付了两个程序员的薪水。结对编程只是（理论上）在相同时间内从这两者中获得更多调试和工作软件的一种方式。
于 2009-03-26T22:14:27.960 回答
1
结对编程的概念不是非黑即白的东西，也不是任何类型的灵丹妙药。
由于各种原因，结对编程通常非常有效，但如果做得好，也会非常累人（在我看来，无论如何）——这意味着一个好的结对可能每天最多结对编程几个小时。当然，这应该被鼓励，但不是强制性的，尤其是在 100% 的时间里不是强制性的，因为这似乎很难管理（以持续的效率和无论如何都没有啤酒）。
所以，结对编程只是解决问题的一种方式，我发现很难从问题的角度来看待它。这不像您需要为此雇用两倍的开发人员。这就像想知道是否值得雇用一个消息男孩/女孩让同一部门的两名员工相互交谈......当明显的解决方案是让他们直接相互交谈而不需要额外的信使时。
于 2009-04-30T17:12:52.447 回答
0
我还没有完成统计数据——我怀疑你很难进行统计上有效的研究——但请记住生成工作、无错误代码的表面目标——而不仅仅是代码数量。一对好的组合应该能够创建至少与两个单独工作的程序员一样多的正确代码。
于 2009-04-20T04:42:26.857 回答