结对编程意味着每个开发者双倍的花费 这值钱吗？
在敏捷结对编程要求我们加倍支付给单个程序员的工资。 当然，用这种方法代码的质量好得多，错误发现得早得多，但是这样还是值得的？ 也许我们应该把第二个开发人员的工资交给less数testing人员（后者通常比合格的程序员便宜）？ 有没有人有这样的比较经验？
你怎么知道你的不成熟的程序员更有效率？ 我有时候觉得这个单/双可以和兔子和乌龟的老童话相媲美。
配对不会陷入适得其反的工作日子。 我不知道我多less次看到开发人员花费数周的时间来处理那些后来变成更简单的东西。 单个程序员“在区域”往往是愚蠢的东西。 产生太多代码太简单了，而当你想要的代码更less时，就会更多。
在后代，当尘埃落定的时候，你会发现数百，甚至数千行的代码，因为有人不知道库X或者技术Y而不能写出来。配对改善了这个问题，但并没有消除它。 它鼓励个人和这对人在进入无意识的代码欣快之前做更多的研究。
我希望我能够配对更多….
我们在公司中使用这种方法，但是只能用于困难的任务，或者当您不确定别人已经开展的工作时，我相信这些工作是非常好的。 它可以帮助你避免陷入窘境，并且能够在必要时将想法反popup来，同时还能够独立完成最简单的任务。
我也相信这比代码审查更有利，这是我们在工作的地方做的其他事情。 在没有提供重要的上下文的情况下进行代码审查时，往往很难完全知道发生了什么事情，在这种情况下，您并不总是有时间思考所有进出的问题。 结对编程从一开始就为您提供了上下文，并让您花更多时间思考边界情况，这些情况可能会导致问题，也可能不会导致问题。
虽然我同意迄今为止关于结对编程是好事的回应，但我会扮演魔鬼的拥护者，并认为这并不总是有道理的。
当你配对时，你不会得到一个有两倍大脑的程序员。 你得到一个程序员，这是你的大脑的联合 。 所以基本上任何时候，我搞砸了，我的伙伴抓住或find一些更好的方式，这是一个加号。 但是，任何时候我自己写正确的代码都是浪费钱，因为我的合作伙伴是不需要的。
基本上，你需要评估你正在处理的代码。 简单的任务通常是不值得花钱的人坐在肩上，并确保你正确地写了你的循环。 然而，在一定的门槛上，这些任务非常复杂，足以使配对编程的合理性成为可能。
通过配对编程，可以结合使用：
- 更高质量的代码
- 更好地分配内部知识
- 更多的团队精神
你不会得到那么多的投资回报。
再一次，你不应该把它用于所有的任务。
如果花费不到一个开发者所花费的时间的一半，这并不意味着成本的两倍。 我想在困难或低级别的任务，这将是有益的。 我发现这是值得的，因为你有人说“不，不要这样做！” 很久以前，它会在生产代码中最终花费你的时间和金钱。
我已经编写了操作系统和这种性质的东西，这是非常有价值的，有人坐在我旁边仔细检查我的逻辑。
不，你不知道。 每个程序员仍然得到一个工资。
如果你不把它称为“结对编程”，你认为你的程序员不会互相交谈吗？ 你认为编程是完全可并行的吗？
很难说 – 我花了很多时间在强制配对的环境中工作，也在配对的可选环境中工作。 我见过的最高质量的代码不在配对环境中。 这可能与个人开发者的素质和纪律有关。 有时你会从配对中得到你的钱，特别是在一些编码器不是顶级的情况下。 但是，如果所有的编码员都是有经验的，有纪律的编码员，那么如果他们一直在进行配对，那么就是在浪费你的钱。
我曾多次对我的编码规则和产品质量产生巨大影响的一种体验是：携带寻呼机。 当我必须支持我编码的系统时，它会改变我编码的方式。 也就是说，我编码的方式，以保持传呼机不起飞。 结果是产品质量更好，代码质量也更好。 我见过的编码器从来没有传过寻呼机产生更脆弱的代码。 直到他们得到支持，他们才能理解和改进。
在工作中，我们一直使用结对编程。 诀窍是要知道哪些任务应该成对完成，哪些是两个开发人员完成的“浪费时间”。 大拇指的规则是，更多研究导向的任务（即POCs和尖峰）应该成对并且发展新的特征（以便知识将存在于不止一个想法中）。 一个开发人员可以完成诸如CI服务器安装或插件图标replace等更为庞大的任务。 另一个因素是目前团队成员的可用性以及目前在这个迭代中要完成的任务。
结对编程可以是非常有效的，但是你不应该成对雇用程序员。 你不能强迫开发者配对程序。 它只有在两个开发人员点击并决定他们可以彼此学习并且共同构build一个令人敬畏的东西时才起作用。 我的build议是聘请尽可能多的最聪明的开发人员，并把他们放在一个自然适合鼓励兼职配对编程的环境中。 开发人员需要能够独自编码，而且还要与团队中的其他人交谈。
find适合自己和公司的正确组合，将会比科学更具艺术性，当然也不是盲目地遵循某些已发表方法的要求所能做的。
也就是说，在检查之前，你压扁的bug越多，从长远来看就越节省。 让另外一个开发人员在构build某个东西的时候总是比后来的testing人员更有效。 我会把它叫做花钱。
越早find缺陷/缺陷就越便宜，所以使用这笔钱来雇佣更多的QA人员与其他开发人员，由于从DEV到QA有多less次旅行，您将花费更多时间/金钱。
话虽如此，搭配编程并不适合所有人，有些开发者不配对，互相分心，花时间等等。
如果你有开发人员可以配对程序，那么从长远来看，如果你添加更多可维护的代码，减less缺陷，减less质量保证时间，最重要的是，如果其中一位开发人员遇到公交车，不必等到有人在项目上做更多的工作之后才能加快项目速度。
如果你的开发人员不能配对，不要强迫他们进入，所有你要做的就是浪费时间和金钱。
结对编程的第一个假设是故事卡要花费两倍的成本。 这个假设是错误的。 这是为什么？
- 改进的质量 ：一对在同一个故事卡上工作的活跃程序员将完成卡的缺陷较less
- 提高生产力 ：如果在解决问题时没有完全封锁，那么一对子就不太可能放慢速度。 而且，当你和一个合作伙伴一起工作的时候，要收到电子邮件或者networking假期比较困难……你不想让合作伙伴失望。 你将会用更简洁的devise和更less的代码来解决问题
- 消除知识的孤岛 ：通过旋转对，您将学习整个团队的应用程序和领域业务知识。 由于休假期间没有其他人知道她的代码，队伍不太可能被封锁。
- 知识转移：旋转对在彼此协作的过程中教授新技能（工程和领域）。 团队的水平会上升，知识通过团队传播。
- 团队自我select：团队学习一种花药的技能，并迅速淘汰一个没有执行的人。
从实际经验来看，我们看到了明显的缺陷。 可以添加新的团队成员，而不会减慢团队（尝试使用非配对团队）。 对于一个试验，一个团队估计了一套故事卡的工作，好像六个单独的开发者将单独完成代码。 随后，六位开发者被告知配对。 他们按时完成了高质量的工作。 如果你不搭配，你花了很多时间来提供less量的质量，你没有办法规模，你有太多的专业知识孤岛。
在第二个例子中，我们估计要完成这个工作，要求我们需要一个团队从4对到7对。 我们给了自己一个月的时间在车上。 我们将一名新开发人员与一位经验丰富的开发人员配对，并通过故事卡片轮转对子 团队在计划的时间内完成了所有可交付成果。 没有配对，就不可能有6名开发者join到8名开发者的团队中，
底线，你会省钱配对。 您将采取同一时间，更高质量的交付，提高团队的performance，技能和知识，并除掉死木。 您的储蓄将以可持续的速度进行，并且可以大大减less宕机的速度。
前提是你的生产力不止双打。 部分收益是马上实现的（例如，在代码签入之前），并且部分在更less的错误和故障时被进一步实现。
当我用两个学期的经验教授学生时， 对于大多数成对学生来说，他们的工作效率超过了两倍，因为他们互相问了问题，他们学得更快，学得更快。 但这不是普遍的事实; 一对差劲的配对可能会花费更长的时间，而且比技能更高的一半还差。
来自其他许多行业的质量pipe理经验告诉我们，长期来看， 缺陷预防比缺陷检测 （也称为QA）和后续修复更便宜。
他们还了解到，从长远来看 ，大多数情况下是1到2年，这意味着你的投资在那之后就可以得到回报。 考虑到这个规模的投资通常会在4年后达到一个突破，这是相当不错的！
问题在于，其他行业需要数十年的时间来积累足够的数据，才能够certificate事实正是如此。 您可以很容易地find数据来支持他们的结论，并以类比的方式得出软件的结论，但是到目前为止，软件业务是没有证据的。
这就是说，我相信类似的结论是有效的：一对开发人员和一个testing人员比一个开发人员和两个testing人员更有成效。
如果你有两个昂贵的开发者坐在一台计算机前面去讨论pipe理问题，还有很多其他的东西可以帮助防止缺陷，但是对于pipe理层来说却不那么明显（因此也很刺激）。
当我在朋友的船上编程时，我们并不总是有时间，因为我们中的一个人正在航行，而另一个正在编码。 然而，当我们被锚定或在平静的水中，我们可以做配对编程，它工作正常。
结对编程不会使成本增加一倍 – 它只是减less了键入的数量。 打字不是编程。 完成软件中的function是编程。 这是解决问题的方法 你不能用input的代码行来测量它。 一些程序员会使用更好的algorithm，所以他们最终input较less。
你如何定义物有所值？ 在开始编码和完成之间可能总的时间已经过去，在工作中的function？
不配对的成本往往不是正确的计算：问题是，大多数人没有衡量缺陷的数量或额外的时间来解决工作，而不是正确完成的工作 – 他们只是衡量首先是“把工作放在栅栏上”的时间。
在配对时，有一些测量生产力的尝试，但不幸的是，它与“交付的代码行数”有一定的关系 – 这是一个虚假指标。
你可能会发现这个研究是相关的： http : laurie/Papers/XPSardinia.PDF
没门！ 在我工作的公司里，我们练习了很多配对编程！ 它使事情真的很快，真的很有效！ 只是试试！ 你会稍后评估它！
NC州Laurie Williams教授是学术界关于配对编程有效性的主要权威，她对此做了大量的研究。
如果你想要“官方文字”，请访问她的出版物清单。
她的文章“加强配对编程”非常有名。
这取决于开发者。 不幸的是，你不能把任何两个开发人员放在一起，期望得到及时，高质量的结果。 不是每个人都为了配对的编程而被切断，甚至是在敏捷的开发环境中工作。 关于配对编程的两件事，我认为值得：（1）开发人员之间的交叉培训; 和（2）实时同行评审。 交叉培训将有助于加强整个团队的技能，实时同行评审可以消除对正式同行评审的需求。 多年来，我从同龄人那里学到的知识比从前在技术培训中学到的要多。
除非你是一个非常小的商店，否则你可能已经支付了两位程序员的工资。 结对编程只是一种（理论上）在相同的时间内从这两个中调出更多的debugging和工作软件的方法。
结对编程的概念并不是什么黑白相间的东西，也不是一个silverlight的子弹。
结对编程通常是非常有效的，因为各种原因，但做得很对（这在我看来也是很费力的），也就是说，一对好的对可能每天最多花费几个小时。 当然这应该鼓励，但是没有规定，特别是在100％时间没有规定，因为这似乎很难pipe理（持续的效率和无啤酒）。
所以，结对编程只是解决问题的一种方式，从问题的angular度来看，我觉得很难看。 这不像是你需要聘用两倍于此的开发人员。 这是想知道是否值得聘用一个消息男孩/女孩，让同一部门的两名员工互相交谈…当明显的解决办法是让他们直接互相交谈，没有额外的使者。
我还没有完成统计数据 – 而且我怀疑你要做一个统计上有效的研究很困难 – 但要记住生成工作，无差错代码的表面目标 – 不仅仅是代码数量。 好的一对应该能够创build至less与两个程序员分开工作的正确的代码。
