结对编程意味着每个开发人员的成 这笔钱值得吗?

Hen*_*sek 40 agile methodology pair-programming

在Agile中进行结对编程需要我们将单个程序员的薪水加倍.当然,采用这种方法,代码的质量要好得多,早期发现的错误等等,但仍然值得花钱吗?也许我们应该向少数测试人员支付第二个开发人员的工资(后者通常比合格的程序员便宜得多)?有没有人有这种比较的经验?

kro*_*old 53

你怎么知道你的不成对的程序员更有效率?我有时认为单/双与兔子和乌龟的旧童话相当.

配对不会影响到适得其反的工作.我不知道我多久经常看到开发人员花费数周时间处理后来被更简单的东西取代的东西."在区域内"的单个程序员经常做蠢事.生成太多代码太简单了,当你想要的东西更多时,代码更少.

在后代,当尘埃落定时,你会发现数百个,如果不是数千行代码,由于有人不知道库X或技术Y 而无法编写.配对可以改善这个问题,但不会删除它.在鼓励无意识的代码兴奋之前,它鼓励个人和两人做更多的研究.

我希望我能配对......

  • 作为一名经验丰富的开发人员,我可以告诉你,在配对工作中,典型的任务需要花费2-3倍的时间(由于解释我在做什么以及为什么),但如果我单独完成这项工作,我就减少了人数如果需要,谁可以迅速加快这段代码的速度. (4认同)

Ian*_*Ian 17

我们在公司中使用这种方法,但仅针对困难的任务,或者当您不确定其他人已经开展的工作时,我认为这些工作非常有效.它可以帮助您避免陷入困境,并且能够在必要时将想法从人们身上移开,同时仍能够独立完成大多数简单任务.

我也相信它比代码审查更有益,这是我工作的地方.在没有提供重要的背景信息的情况下进行代码审查时,通常很难完全了解正在进行的操作,此时您并不总是有时间考虑所有的内部和外部.结对编程从一开始就为您提供上下文,并允许您花更多时间考虑可能会或可能不会导致问题的边缘情况.


Jac*_*ams 15

虽然我同意目前关于结对编程是一件好事的大部分反应,但我会扮演魔鬼的拥护者,并认为它并不总是有意义的.

当你配对时,你不会得到一个拥有两倍大脑的程序员.你得到一个程序员是这样的工会双方你的大脑中的.因此,基本上任何时候我搞砸了,我的伴侣抓住或找到更好的方式,这是一个加号.但是,任何时候我自己编写正确的代码都是浪费钱,因为不需要我的伴侣.

基本上,您需要评估您正在处理的代码.简单的任务通常不值得花钱让别人坐在肩上并确保你正确地编写你的for循环.然而,在某个阈值处,任务足够复杂以使对编程的roi合理.

  • 反对这一点的一点是在结对编程期间传达知识.如果您自己编写正确的代码,并且有人在观察您,他们可能会学习更好的方法来做某事,并且他们可能会更熟悉问题,库和代码库. (2认同)
  • 我同意,但我的观点是结对编程对于简单的任务没有意义.可能性很小,如果任务很简单,很少会传授知识.如果我只是将值放入和放出文本框,那么你并没有真正学到任何东西,因为希望你应该已经知道如何做到这一点.在这种情况下,结对编程仍然毫无意义 (2认同)

Joe*_*ips 12

如果花费的时间少于一个开发时间的1/2,这并不意味着成本增加一倍.我认为在困难或低级别的任务中,这会有所帮助.我发现这是值得的,因为你有人说"不,不要这样做!" 很久之后,它最终会出现在生产代码中,这将花费你的时间和金钱.

我编写了操作系统和那种性质的东西,有人坐在我旁边仔细检查我的逻辑是非常宝贵的.


Too*_*the 12

使用结对编程,您可以组合:

  • 更高质量的代码
  • 更好地分配内在知识
  • 更多的团队精神

你不会比这更容易获得那么多的投资回报.

然后,您不应该将它用于所有任务.

  • @Gamecat - 总的来说,我同意你的看法.您不一定能获得更高质量的代码.我确实在非配对环境中看到了更高的q代码.更多团队精神?如果强制配对则不行.我去过那里,那个太快了!当然,这也不是敏捷.你可以通过配对来鼓励你列出的东西. (2认同)

Dro*_*per 8

在工作中,我们一直使用结对编程.诀窍是知道应该成对完成哪些任务,如果由两个开发人员完成,那将是"浪费时间".拇指的规则是更加面向研究的任务(即POC和尖峰)应该成对完成以及开发新特征(这样知识将存在于多个思想中).诸如CI服务器安装或替换插件图标等更为简洁的任务由单个开发人员完成.另一个因素是团队成员的当前可用性以及在该迭代中要完成的当前任务.


小智 7

不,你没有.每个程序员仍然得到一个薪水.

如果你不把它称为"结对编程",你认为你的程序员不会互相交谈吗?您认为编程是完全可并行化的吗?


Don*_*son 7

很难说 - 我花了很多时间在一个强制配对环境中工作,也在配对可选环境中工作.我见过的最高质量的代码不在配对环境中.这可能更多地与个体开发者的能力和纪律有关.有时你会从配对中获得你的钱,特别是在一些编码员不是顶级的情况下.但是,如果所有的编码器都是经验丰富,训练有素的程序员,你只是在浪费你的钱,如果他们配对所有的时间.

我曾多次对我的编码规则和我生产的产品质量产生巨大影响的一种体验是:携带寻呼机.当我必须支持我编码的系统时,它会改变我编码的方式.也就是说,我以这样的方式编码,以防止该寻呼机熄灭.结果是产品质量更好,通常代码质量也更好.我见过的那些从未携带过寻呼机的编码器产生的代码更脆弱.在他们获得支持之前,他们甚至无法理解和改进.


Bob*_*tor 6

越早找到错误/缺陷就越便宜,因此使用这笔资金来雇用更多的qa人与另一个开发人员相比,由于从DEV到QA的次数多少,这将花费你更多的时间/金钱.

说到这一点,对编程不适合所有人,一些开发人员不配对,他们分散注意力,花费所有时间战斗等.

如果您有可以配对程序的开发人员,那么从长远来看,当您添加更易维护的代码,更低的缺陷以便更少的QA时间,以及最重要的是如果其中一个开发人员受到总线命中,那么就更有益了在完成任何更多工作之前,不必等待某人加快项目进度.

如果您的开发人员无法配对程序,请不要强迫他们加入,所有您要做的就是浪费时间和金钱.


i_a*_*orf 6

结对编程可能非常有效,但是你不应该成对雇佣程序员.你不能强迫开发人员配对程序.它只适用于两个开发人员点击并决定他们可以相互学习并一起构建一些非常棒的东西.我的建议是雇用尽可能多的最聪明的开发人员,并将其置于一个自然有助于鼓励兼职配对编程的环境中.开发人员需要能够单独编写代码,还需要与团队中的其他人讨论相关问题.

寻找适合您和您公司的合适组合将更多的是艺术而不是科学,当然也不是盲目地遵循某些已发表的方法的要求.

也就是说,你在签入之前压扁的bug越多,从长远来看你节省的就越多.让另一位开发人员在构建一些东西时看起来总是比在之后使用测试器黑盒子更有效.我称之为花钱.


Cam*_*lff 5

结对编程的第一个假设是故事卡的开发成本是其两倍。假设是错误的。这是为什么?

  • 提高质量:一对活跃的程序员在同一张故事卡上工作将完成卡的缺陷更少
  • 提高生产力:如果在解决问题时没有完全阻止,一对不太可能放慢速度。此外,当您与合作伙伴一起工作时,很难通过电子邮件或网络休假……您不想让合作伙伴失望。成对工作时,您将通过更简洁的设计和更少的代码行来解决问题
  • 消除知识孤岛:通过轮换对,您将学习整个团队的应用程序和领域业务知识。团队不太可能被阻止,因为 Sue 在休假并且没有人知道她的代码。
  • 知识转移:轮换组在合作时互相传授新技能(工程和领域)。每个人的团队水平都会提高,知识在团队中传播。
  • 团队自我选择:团队学习一个花药的技能,并会迅速淘汰一个表现不佳的人。

根据实际经验,我们已经看到缺陷显着下降。可以在不减慢团队速度的情况下添加新团队成员(尝试与非配对团队一起使用)。在试验中,一个团队估计一组故事卡的工作,就好像六个单独的开发人员将单独完成代码一样。然后告诉六名开发人员配对。他们按时高质量完成了工作。如果您不配对,您将花费大量时间交付低质量的产品,您无法扩展,并且您拥有太多的专业知识。

在第二个例子中,我们估计要在要求的时间内完成工作,我们需要将一个团队从 4 对增加到 7 对。我们给了自己 1 个月的时间来加入新对。我们将新开发人员与经验丰富的开发人员配对,并在故事卡上轮换。该团队在计划的时间内按质量完成了所有可交付成果。如果没有配对,就不可能将 6 个开发人员添加到 8 个开发人员的团队中并达到目标!

最重要的是,您可以通过配对来省钱。您将花费大约相同的时间,以更高的质量交付,提高团队的绩效、技能和知识并清除死木。您的储蓄将伴随着可持续的步伐和显着减少导致团队放缓的缺陷。