blocks|key|497594|text|我们在公司中使用这种方法，但只在困难的任务中使用，或者当你不确定其他人已经在做的事情时，我相信效果很好。它可以让你避免墨守成规，能够在必要的时候向人们提出想法，同时仍然能够独立完成大多数简单的任务。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|497595|我也相信它比代码审查更有好处，这是我工作的地方做的另一件事。在不提供重要上下文的情况下进行代码审查时，通常很难完全知道发生了什么，此时您并不总是有时间考虑所有的输入和输出。结对编程从一开始就给了您该上下文，并允许您花更多的时间考虑可能会或可能不会导致问题的边缘情况。|497596|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We use this approach in our company, but only for the difficult tasks or when you're unsure about something someone else has worked on already which I believe works very well. It saves you getting stuck in a rut and being able to bounce ideas off people where necessary while still being able to work independently for most simple tasks.

I also believe it is more beneficial than a code review, which is something else we do where I work. It is often difficult to know fully what's going on when doing a code review without providing significant context, at which point you don't always have the time to think about all the in's and out's. Pair programming gives you that context from the start and allows you to spend more time thinking about edge cases that may or may not cause problems.

blocks|key|4562533|text|如果它花费的时间不到一个开发人员的1/2，这并不意味着成本增加了一倍。我认为对于困难或低级别的任务，这将是有帮助的。我发现这是值得的，因为你已经有人说“不，不要那样做！”在它最终进入生产代码之前很久，它将真正耗费您的时间和金钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4562534|我写过操作系统之类的东西，其中有人坐在我旁边仔细检查我的逻辑，这是非常有价值的。|4562535|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It does not mean double the cost if it takes less than 1/2 the time it would have taken with one dev. I think on difficult or low-level tasks this would be helpful. I find that it's worth it because you've got someone to say "no, don't do THAT!" long before it ends up in production code where it will REALLY cost you time and money.

I've written operating systems and things of that nature where it was invaluable that someone was sitting next to me to double check my logic.

blocks|key|4562625|text|你怎么知道你没有配对的程序员更有效率呢？我有时会想，这对情侣就像古老的童话里的兔子和乌龟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4562626|结对并不会让你的工作变得事与愿违。我不知道有多少次我看到开发人员花了几周的时间在一些后来被简单得多的东西取代的东西上。单独的程序员“在专区”经常做一些愚蠢的事情。当你想要的是用更少的代码产生更多的冲力时，产生太多的代码太容易了。|4562627|在后代中，当尘埃落定时，你会发现成百上千行的代码可能没有被写出来，因为有人不知道库X或技术Y。配对改善了这个问题，但没有消除它。它鼓励每个人和两个人在进入盲目的代码快感之前做更多的研究。|4562628|我希望我能有更多的配对...|4562629|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

How do you know your unpaired programmers are any more efficient ? I sometimes think the single/pair is comparable to the old fairytale of the rabbit and the tortoise.

Pairing doesn't drift off into days of counter-productive work. I have no idea of how often I've seen developers spending weeks working on stuff that later turns out to be replaced by something far simpler. The single programmer "in the zone" often does stupid things. It's just too easy to produce too much code, when what you want is more punch with less code.

And in posterity, when the dust settles, you find hundreds, if not thousands of lines of code that could have been not written because someone didn't know about library X or technique Y. Pairing improves this problem, but does not remove it. It encourages both individuals and the pair to do more research before diving into mindless code euphoria.

I wish I was able to pair more....

blocks|key|3717536|text|在工作中，我们一直使用结对编程。诀窍是知道哪些任务应该成对完成，哪些任务如果由两个开发人员完成会“浪费时间”。经验法则是，更多面向研究的任务(即POC和spikes)应该成对完成，并开发新功能(以便知识将存在于多个头脑中)。更普通的任务，比如CI服务器安装或更换插件图标，都是由一个开发人员完成的。另一个因素是团队成员的当前可用性以及在该迭代中要完成的当前任务。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3717537|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

At work we use pair programming all the time.
The trick is to know which tasks should be done in pair and which would be a "waste of time" if done by two developers.
The rule of the thumb is that tasks that are more research oriented (i.e. POCs &amp; spikes) should be done in pairs as well as development of new features (so that the knowledge will exist in more than one mind).
Tasks that are more mundain such as CI server installation or replacement of the addon icons is done by a single developer.
Another factor is the current availability of team members and the current tasks to be done at that iteration.

blocks|key|1109602|text|bug/缺陷越早被发现，修复的成本就越低，所以用这笔钱雇佣更多的QA人员而不是另一个开发人员，会花费你更多的时间/金钱，因为从DEV到qa的行程太多了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109603|话虽如此，结对编程并不适用于每个人，一些开发人员结对不好，他们互相分心，把所有时间都花在打架上，等等。|1109604|如果你有可以配对编程的开发人员，当你添加更多可维护的代码，减少缺陷，减少QA时间，并且最重要的是，如果其中一个开发人员被公交车撞到，你不必等待某人在项目上加快速度，然后才能完成更多的工作，从长远来看，这可能会带来更多的好处。|1109605|如果你的开发人员不能配对程序，不要强迫他们去做，你所要做的就是浪费时间和金钱。|1109606|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more qa people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.

Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc. 

If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.

If your developers can't pair program don't force them into it, all you're going to do is waste time and money.

blocks|key|3717665|text|通过结对编程，您可以结合以下几点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3717666|3717667|更高质量的代码|unordered-list-item|3717668|更好地分发内部知识|3717669|更具团队精神|3717670|3717671|你不会比这更容易获得那么多的投资回报。|3717672|再说一次，你不应该在所有任务中都使用它。|3717673|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|U|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

With pair programming, you combine:

<ul>
<li>Higher quality code</li>
<li>Better distribution of inner knowledge</li>
<li>More team spirit</li>
</ul>

You won't get that much return on investment easier than that.

Then again, you shouldn't use it for all tasks.

blocks|key|497933|text|虽然我同意到目前为止关于结对编程是一件好事的大多数反应，但我将扮演魔鬼的倡导者，并认为它并不总是有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|497934|当你们结对时，你不会得到一个拥有双倍智慧的程序员。你得到了一个程序员，他是你们两个人的联盟。所以基本上，任何时候我搞砸了，而我的伴侣抓住了或者找到了更好的方法，这都是一个加分。然而，任何时候我自己写正确的代码都是浪费钱，因为不需要我的合作伙伴。|offset|length|style|BOLD|497935|基本上，您需要评估您正在处理的代码。简单的任务通常不值得花钱让人坐下来确保你写的for循环是正确的。然而，在某些阈值下，任务足够复杂，使得结对编程的roi是合理的。|497936|entityMap^0|0|17|2|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Although I agree with most of the response so far about pair programming being a good thing, I will play devil's advocate and argue that it doesn't always make sense.

When you pair you don't get a programmer that's got twice the brains. You get a programmer that's the union of both of your brains. So basically any time that I screw up and my partner catches or finds some way better, it's a plus. However, any time that I write the correct code on my own is a waste of money since my partner wasn't needed.

Basically, you need to evaluate the code you're working on. Simple tasks are usually not worth the money to pay someone to sit over shoulder and make sure you wrote your for loop correctly. However, at some threshold, the tasks are complicated enough to make the roi for pair programming justifiable.

blocks|key|1109694|text|前提是你的工作效率提高了一倍以上。部分收益立即实现(例如，在代码签入之前)，当错误和失败较少时，部分收益将进一步实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109695|当我用两个学期的经验教学生时，对于大多数结对的学生来说，他们的工作效率提高了一倍以上，因为他们互相问问题，而且学习和完成得更快。但这并不是普遍正确的；配对不佳的一对可能需要更长的时间，而且比技术更熟练的那一半做得更差。|1109696|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The premise is that your productivity more than doubles. Part of the gain is realized right away (e.g., before code is checked in) and part is realized further on, when there are fewer bugs and failures.

When I teach students with two semesters' experience, for most pairs their productivity more than doubles because they ask each other questions and they learn and finish faster. But it's not universally true; a badly matched pair can take longer and do worse than the more skilled half.

blocks|key|1109710|text|不，你没有。每个程序员仍然只有一份薪水。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109711|你认为如果你不把它叫做“结对编程”，你的程序员就不会互相交谈吗？你认为编程是完全可并行化的吗？|1109712|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No, you don't. Each programmer still gets exactly one salary.

Do you think your programmers won't talk to each other if you don't call it "pair programming"? Do you think programming is perfectly parallelizable?

blocks|key|3717844|text|结对编程可以是非常有效的，但是你不应该雇佣结对的程序员。你不能强迫开发人员结对编程。只有当两个开发人员点击并决定他们可以相互学习并共同构建一些令人惊叹的东西时，它才有效。我的建议是，尽可能多地雇佣你能找到的最聪明的开发人员，并将他们放在一个自然有利于鼓励兼职结对编程的环境中。开发人员需要能够单独编写代码，但也需要与团队中的其他人讨论这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3717845|找到适合你和你的公司的正确组合将更像是艺术而不是科学，当然也不是盲目遵循一些已发表的方法的要求就能做到的事情。|3717846|也就是说，在bug被检入之前，您压碎的bug越多，从长远来看，您节省的就越多。让另一个开发人员看着你架构一些东西，总是比事后让一个测试人员黑箱操作更有效。我称之为物有所值。|3717847|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Pair programming can be amazingly effective, however you shouldn't be hiring programmers in pairs. You can't force developers to pair program. It only works when two developers click and decide they can learn from each other and build something awesome together. My advice is to hire as many of the smartest developers you can find and put them in a setting that naturally lends itself to encouraging part-time pair programming. Developers need to be able to code alone, but also talk to others on the team about it.

Finding the right mix that works for you and your company will be more art than science, and certainly not something you can do by blindly following the demands of some published methodology. 

That said, the more bugs you squash before they ever get checked in, the more you save in the long run. Having another developer looking on as you architect something will always be more effective than having a tester black-box it afterward. I'd call it money well spent.

blocks|key|498100|text|来自其他许多行业的质量管理经验告诉我们，从长远来看，缺陷预防比缺陷检测(也称为QA)和后续修复更便宜。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|498101|他们还了解到，在大多数情况下，长期运行的范围从1年到2年，这意味着您的投资在此之后会获得回报。考虑到这种规模的投资通常会在4年后达到收支平衡，这是相当不错的！|498102|问题是，其他行业花了几十年的时间才积累了足够的数据，以便能够证明这是他们的情况。你可以很容易地找到数据来支持他们的结论，并通过类比得出软件的结论，但到今天为止，还没有关于软件业务的证据。|498103|话虽如此，我相信类似的结论是有效的:一对开发人员和一个测试人员比一个开发人员和两个测试人员更有效率。|498104|如果你在向管理层证明两个昂贵的开发人员坐在一台计算机前是有问题的，那么还有许多其他的东西可以帮助防止缺陷，但对管理层来说不是那么明显(因此令人恼火)。|498105|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Quality management experience from other many industries teaches us that defect prevention is cheaper in the long run than defect detection (also known as QA) and subsequent fixing. 

They also learned that the long run ranges in most cases from 1 to 2 years, which means that your investment pays off after that. Considering that investments on that scale are usually expected to reach a break even after 4 years, this is pretty good!

The problem is that it took the other industries several decades to accumulate enough data for being able to prove that this is the case for them. You can easily find data to support their conclusion and draw a conclusion for software in analogy to that, but as of today, there is no proof for the software business.

That being said, I believe that the analogous conclusion is valid: A pair of developers and one tester are more productive than one developer and two testers.

If you have problems justifying two expensive developers sitting in front of one computer to the managament, there are many other things that help with defect prevention, but are not as visible (and therefore irritating) to the management.

blocks|key|1109819|text|除非你是一个非常小的商店，否则你可能已经支付了两个程序员的工资。结对编程只是一种(理论上)在相同的时间内获得更多经过调试和工作的软件的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109820|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unless you are a very tiny shop, you are probably already paying the salaries of two programmers. Pair programming is just a way to (theoreticaly) get more debugged and working software out of those two in the same amount of time.

blocks|key|1109856|text|我还没有做过统计--我怀疑您很难做一个统计上有效的研究--但请记住，表面上的目标是生成有效的、无错误的代码--而不仅仅是代码的数量。一个好的组合应该至少能够创建与两个单独工作的程序员一样多的正确代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109857|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I haven't done the stats--and I suspect you'd have a hard time doing a statistically valid study--but keep in mind the ostensible objective of producing working, error-free code--not just quantity of code. A good pair should be able to create at least as much correct code as two programmers working separately.

blocks|key|4563168|text|没门，伙计！在我工作的公司，我们练习了很多结对编程！它能让事情做得很快很有效率！试一试吧！您将在稍后对其进行评估！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4563169|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No way man! in the company i'm working we practice a lot of pair-programming! it gets things done really fast and really efficiently! just make a try! you will valuate it later!

blocks|key|1115293|text|这不是非黑即白的东西，也不是任何类型的银弹，结对编程的概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1115294|由于各种原因，结对编程通常是非常高效的，但如果做得正确，它也非常令人精疲力竭(在我看来无论如何)--这意味着一个好的结对编程每天最多可能只有几个小时。当然，这应该得到鼓励，但不是强制的，尤其是不是在100%25的时候强制的，因为这似乎很难管理(具有持续的效率，而且无论如何都没有啤酒)。|1115295|因此，结对编程只是解决问题的一种方式，我发现很难从问题的角度来看待它。你不需要为此雇佣两倍的开发人员。这就像是想知道是否值得雇佣一个消息男孩/女孩让同一部门的两个员工互相交谈……当显而易见的解决方案是让他们直接相互交谈，而不是额外的信使。|1115296|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It's not a black and white thing or a silver bullet of any kind, the concept of pair programming.

Pair programming is generally extremely efficient for various reasons, but done right it's also very exhausting (in my opinion any way) - meaning a good pair might pair program a few hours a day at most. This should be encouraged, of course, but not mandated and especially not mandated at 100% time because that seems hard to manage (with sustained efficiency and no beer anyway).

So, pair programming is just one way of approaching a problem, and I find it hard to look at it from the question's perspective. It's not like you need to hire twice as many developers for this. It's like wondering if it's worth hiring a message boy/girl to have two employees in the same department talk to each other... when the obvious solution is to have them talk to each other directly without an additional messenger.

blocks|key|3718105|text|来自北卡罗来纳州立大学的Laurie+Williams教授是学术界关于结对编程有效性的主要权威，她对此做了一大堆研究。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3718106|如果你想要“官方词汇”，请访问她的publication列表。|offset|length|3718107|她的文章：“加强结对编程的案例”非常有名。|3718108|entityMap|0|LINK|mutability|MUTABLE|url|http://collaboration.csc.ncsu.edu/laurie/publications.html#PairProgramming^0|0|H|B|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Professor Laurie Williams from NC State is the primary authority in academia about the effectiveness of pair programming, she did a whole bunch of studies on this.

If you want the "official word", visit her <a href="http://collaboration.csc.ncsu.edu/laurie/publications.html#PairProgramming" rel="nofollow noreferrer">publication</a> list.

Her article: "Strengthening the Case for Pair-Programming" is extremely famous.

blocks|key|3718145|text|这取决于开发人员。不幸的是，你不能仅仅把任何两个开发人员放在一起，并期望及时、高质量的结果。并不是每个人都适合结对编程，甚至不适合在敏捷开发环境中工作。关于结对编程，我认为有两件事是值得的：(1)开发人员之间的交叉培训；(2)实时同行评审。交叉培训将有助于加强整个团队的技能，实时同行评审可以消除对正式同行评审的需要。这些年来，我从同龄人那里学到的东西比我在技术培训中学到的还要多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3718146|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It depends on the developers. Unfortunately, you can't just stick any two developers together and expect timely, high quality results. Not everybody is cut out for paired programming or even cut out for working in an agile development environment. Two things about paired programming that I think make it worth while are : (1) Cross-training between developers; and (2) Real-time peer reviews. Cross-training will help to strengthen the skills of the team as a whole, and real-time peer reviews can eliminate the need for formal peer reviews. I've learned more from my peers over the years than I ever learned at a technical training.

blocks|key|4563347|text|很难说-我花了很多时间在强制配对环境和配对可选环境中工作。我所见过的最高质量的代码不是在配对环境中。这可能更多地与单个开发人员的能力和纪律有关。有时候，结对会让你的钱花得物有所值，特别是在一些程序员不是顶级程序员的情况下。但是，如果所有的程序员都是经验丰富、训练有素的程序员，如果他们总是结对，那么你就是在浪费钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4563348|我多次经历的一种经历对我的编码规则和我生产的产品质量产生了巨大的影响，那就是:携带寻呼机。当我必须支持我编写代码的系统时，它会改变我编写代码的方式。也就是说，我以这样一种方式编写代码，以防止寻呼机响起。结果是一个更好质量的产品，通常也是更好的代码质量。我见过的那些从来没有携带寻呼机的程序员产生的代码更脆弱。在得到支持之前，他们甚至无法理解和改进这一点。|4563349|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's hard to say - I've spent a lot of time working in a force-paired environment and also in a pairing-optional environment. The highest quality code I've seen is not in the paired environment. That probably has more to do with the caliber and discipline of the individual developers. Sometimes you'll get your money's worth from pairing, especially where some of the coders are not top-tier. But if all the coders are experienced, well-disciplined coders, you're just wasting your money if they're pairing all the time.

One type of experience that I've had multiple times that has a huge impact on my coding discipline and the quality of product I produce is this: carrying a pager. When I have to support a system for which I code, it changes how I code. That is, I code in such a way as to keep that pager from going off. The result is a better quality product, and typically better code quality, too. The coders I've seen that have never carried a pager produce code that's more fragile. It's not something that they can even understand and improve upon until they've been on support.

blocks|key|498572|text|结对编程的第一个假设是，开发一个故事卡的成本是前者的两倍。这个假设是错误的。这就是为什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|498573|498574|Improved+quality：在同一张故事卡上工作的一对活跃程序员将以较少的|unordered-list-item|offset|length|style|BOLD|498575|Improved生产力完成该卡:如果在解决问题时没有完全受阻，一对程序员就不太可能慢下来。此外，当你与合作伙伴一起工作时，更难接受电子邮件或网络度假……你不会想让合伙人失望的。当您作为知识的pair|498576|Eliminate筒仓工作时，您将使用更干净的设计和更少的代码行来解决问题:通过轮换对，您将在整个团队中学习应用程序和领域业务知识。团队不太可能被阻止，因为Sue在度假时，其他人都不知道她的code.|498577|Knowledge转移：轮换对在一起工作时相互传授新的技能(工程和领域)。每个人的团队水平都会提高，知识也会通过团队传播。|498578|Team+self+selects:团队学习另一个人的技能，并将很快淘汰表现不佳的人。|498579|498580|498581|从实际经验来看，我们已经看到缺陷显着下降。可以在不减慢团队速度的情况下添加新的团队成员(尝试使用非配对团队)。对于一个试验，一个团队估计了一组故事卡的工作，就好像六个单独的开发人员将单独完成代码一样。然后，六个开发人员被告知进行配对。他们按时高质量地完成了这项工作。如果不配对，你就会花费太多的时间来交付低质量的产品，你没有办法扩展，你有太多的专业知识。|498582|在第二个例子中，我们估计要在要求的时间内完成工作，我们需要将一个团队从4对增加到7对。我们给自己1个月的时间加入新的组合。我们将一位新开发人员与一位经验丰富的开发人员配对，并在故事卡上轮换配对。团队在计划的时间内以高质量完成了所有可交付成果。如果没有配对，就不可能将6个开发人员添加到8个开发人员的团队中并达到目标！|498583|底线是，结对可以省钱。您将在几乎相同的时间内，以更高的质量交付，提高团队的绩效，技能和知识，并淘汰枯木。你的节省将伴随着可持续的速度和明显更少的缺陷来拖慢团队。|498584|entityMap^0|0|0|0|G|1|0|B|1|0|2S|1|0|1P|1|0|17|1|0|0|0|4X|0|0|4E|0|0|28|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|13|8|@$F|14|G|15|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|16|8|@$F|17|G|18|H|I]]|9|@]|A|$]]|$1|L|3|M|5|E|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|N|3|O|5|E|7|1C|8|@$F|1D|G|1E|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1F|8|@$F|1G|G|1H|H|I]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1K|8|@$F|1L|G|1M|H|I]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1N|8|@$F|1O|G|1P|H|I]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Q|8|@$F|1R|G|1S|H|I]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|10|$]]

The first assumption one makes with pair programming is that a story card will cost twice a much to develop. The assumption is faulty. Here is why?

<ul>
<li>Improved quality: A pair of active programmers working on the same story card will complete the card with less defects</li>
<li>Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair</li>
<li>Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue when on vacation and no one else knows her code.</li>
<li>Knowledge Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team. </li>
<li>Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.</li>
</ul>

From actual experience we have seen defect drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.

In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!

Bottom line, you will save money with pairing. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.

blocks|key|3718322|text|当我在朋友的船上编程时，我们并不总是有时间，因为我们中的一个人在驾驶它，而另一个人在编程。然而，当我们抛锚或在平静的水中时，我们可以进行结对编程，它工作得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3718323|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When I am programming on my friend's boat we don't always have time because one of us is sailing it while the other is coding. However, when we are anchored or in calm water we can do pair programming and it works fine.

blocks|key|3718361|text|结对编程不会使成本加倍--它只是将打字量减半。打字不是编程。在软件中完成功能就是编程。这是解决问题的方式。您不能仅通过键入的代码行来衡量它。一些程序员会使用更好的算法，因此他们最终会减少打字。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3718362|你如何定义物有所值？从编码开始到live中完成的工作功能之间可能经历的总时间？|offset|length|style|BOLD|3718363|不配对的成本通常不会被正确计算：问题是大多数人没有衡量缺陷的数量或修复一开始没有正确完成的工作所花费的额外时间-他们只是衡量了“把工作扔过栅栏”所花费的时间。|3718364|在裁剪时，有一些测量生产率的尝试，但不幸的是，它有点与“交付的代码行数”捆绑在一起--这是一个虚假的指标。|3718365|你可能会发现这项研究相关：+http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF|3718366|entityMap|0|LINK|mutability|MUTABLE|url|http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF^0|0|0|A|0|0|G|0|0|0|D|E|1Q|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@$D|14|E|15|F|G]]|9|@$D|16|E|17|1|18]]|A|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

Pair programming doesn't double the cost - it just halves the amount of typing. Typing isn't programming. Completing the functionality in the software is programming. It's problem solving. You can't just measure it in lines of code typed. Some programmers will use a better algorithm so they end up typing less.

How would you define value for money? Possibly total time elapsed between start of coding and completed, working feature in live?

The cost of not pairing isn't often counted correctly: The problem is that most people don't measure the number of defects or the amount of extra time taken to fix work that wasn't completed properly in the first place - they just measure the time taken to "throw the work over the fence" in the first place.

There are a few attempts at measuring productivity when paring, but unfortunately it gets a bit tied up with "number of lines of code delivered" - which is a bogus metric.

You might find this study relevant: <a href="http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF" rel="nofollow noreferrer">http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF</a>

Pair programming in Agile requires us to double the salary paid to single programmer. Of course with such approach the quality of the code is far cry better, bugs are found much earlier and so forth, but is that still worth that money? Maybe we should pay the 2nd developer's salary to the few testers (the latter are usually much cheaper than the qualified programmer)? Does anybody have any experience with such comparison?

Pair programming means double cost per developer. Is it worth that money?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

敏捷中的结对编程要求我们支付给单个程序员的工资翻倍。当然，使用这种方法，代码的质量要好得多，错误被发现得更早，等等，但这仍然值得花这么多钱吗？也许我们应该向少数几个测试人员支付第二个开发人员的工资(后者通常比合格的程序员便宜得多)？有没有人有过这样的比较经验？

问结对编程意味着每个开发人员的成本加倍。值那么多钱吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问结对编程意味着每个开发人员的成本加倍。值那么多钱吗？EN