在Agile中进行结对编程需要我们将单个程序员的薪水加倍.当然,采用这种方法,代码的质量要好得多,早期发现的错误等等,但仍然值得花钱吗？也许我们应该向少数测试人员支付第二个开发人员的工资(后者通常比合格的程序员便宜得多)？有没有人有这种比较的经验？
你怎么知道你的不成对的程序员更有效率？我有时认为单/双与兔子和乌龟的旧童话相当.
配对不会影响到适得其反的工作.我不知道我多久经常看到开发人员花费数周时间处理后来被更简单的东西取代的东西."在区域内"的单个程序员经常做蠢事.生成太多代码太简单了,当你想要的东西更多时,代码更少.
在后代,当尘埃落定时,你会发现数百个,如果不是数千行代码,由于有人不知道库X或技术Y 而无法编写.配对可以改善这个问题,但不会删除它.在鼓励无意识的代码兴奋之前,它鼓励个人和两人做更多的研究.
我希望我能配对......
我们在公司中使用这种方法,但仅针对困难的任务,或者当您不确定其他人已经开展的工作时,我认为这些工作非常有效.它可以帮助您避免陷入困境,并且能够在必要时将想法从人们身上移开,同时仍能够独立完成大多数简单任务.
我也相信它比代码审查更有益,这是我工作的地方.在没有提供重要的背景信息的情况下进行代码审查时,通常很难完全了解正在进行的操作,此时您并不总是有时间考虑所有的内部和外部.结对编程从一开始就为您提供上下文,并允许您花更多时间考虑可能会或可能不会导致问题的边缘情况.
虽然我同意目前关于结对编程是一件好事的大部分反应,但我会扮演魔鬼的拥护者,并认为它并不总是有意义的.
当你配对时,你不会得到一个拥有两倍大脑的程序员.你得到一个程序员是这样的工会双方你的大脑中的.因此,基本上任何时候我搞砸了,我的伴侣抓住或找到更好的方式,这是一个加号.但是,任何时候我自己编写正确的代码都是浪费钱,因为不需要我的伴侣.
基本上,您需要评估您正在处理的代码.简单的任务通常不值得花钱让别人坐在肩上并确保你正确地编写你的for循环.然而,在某个阈值处,任务足够复杂以使对编程的roi合理.
如果花费的时间少于一个开发时间的1/2,这并不意味着成本增加一倍.我认为在困难或低级别的任务中,这会有所帮助.我发现这是值得的,因为你有人说"不,不要这样做!" 很久之后,它最终会出现在生产代码中,这将花费你的时间和金钱.
我编写了操作系统和那种性质的东西,有人坐在我旁边仔细检查我的逻辑是非常宝贵的.
使用结对编程,您可以组合:
更高质量的代码
更好地分配内在知识
更多的团队精神
你不会比这更容易获得那么多的投资回报.
然后,您不应该将它用于所有任务.
在工作中,我们一直使用结对编程.诀窍是知道应该成对完成哪些任务,如果由两个开发人员完成,那将是"浪费时间".拇指的规则是更加面向研究的任务(即POC和尖峰)应该成对完成以及开发新特征(这样知识将存在于多个思想中).诸如CI服务器安装或替换插件图标等更为简洁的任务由单个开发人员完成.另一个因素是团队成员的当前可用性以及在该迭代中要完成的当前任务.
不,你没有.每个程序员仍然得到一个薪水.
如果你不把它称为"结对编程",你认为你的程序员不会互相交谈吗？您认为编程是完全可并行化的吗？
很难说 - 我花了很多时间在一个强制配对环境中工作,也在配对可选环境中工作.我见过的最高质量的代码不在配对环境中.这可能更多地与个体开发者的能力和纪律有关.有时你会从配对中获得你的钱,特别是在一些编码员不是顶级的情况下.但是,如果所有的编码器都是经验丰富,训练有素的程序员,你只是在浪费你的钱,如果他们配对所有的时间.
我曾多次对我的编码规则和我生产的产品质量产生巨大影响的一种体验是:携带寻呼机.当我必须支持我编码的系统时,它会改变我编码的方式.也就是说,我以这样的方式编码,以防止该寻呼机熄灭.结果是产品质量更好,通常代码质量也更好.我见过的那些从未携带过寻呼机的编码器产生的代码更脆弱.在他们获得支持之前,他们甚至无法理解和改进.
越早找到错误/缺陷就越便宜,因此使用这笔资金来雇用更多的qa人与另一个开发人员相比,由于从DEV到QA的次数多少,这将花费你更多的时间/金钱.
说到这一点,对编程不适合所有人,一些开发人员不配对,他们分散注意力,花费所有时间战斗等.
如果您有可以配对程序的开发人员,那么从长远来看,当您添加更易维护的代码,更低的缺陷以便更少的QA时间,以及最重要的是如果其中一个开发人员受到总线命中,那么就更有益了在完成任何更多工作之前,不必等待某人加快项目进度.
如果您的开发人员无法配对程序,请不要强迫他们加入,所有您要做的就是浪费时间和金钱.
结对编程可能非常有效,但是你不应该成对雇佣程序员.你不能强迫开发人员配对程序.它只适用于两个开发人员点击并决定他们可以相互学习并一起构建一些非常棒的东西.我的建议是雇用尽可能多的最聪明的开发人员,并将其置于一个自然有助于鼓励兼职配对编程的环境中.开发人员需要能够单独编写代码,还需要与团队中的其他人讨论相关问题.
寻找适合您和您公司的合适组合将更多的是艺术而不是科学,当然也不是盲目地遵循某些已发表的方法的要求.
也就是说,你在签入之前压扁的bug越多,从长远来看你节省的就越多.让另一位开发人员在构建一些东西时看起来总是比在之后使用测试器黑盒子更有效.我称之为花钱.
京公网安备 11010802040832号 | 京ICP备19059560号-6 