为什么结对工作

　　传统代码评审过程涉及两个角色：作者和评审者。结对编程把作者和评审者的工作融为一项任务。代码评审工具也由低速，脱节的会话现在变成了高速，实时的会话。

　　这样问题一旦发生就被修复，真的节省了时间。

　　每一个类，每一个方法，每一行代码都是要解决的小问题。我们写代码时，每一步用这样的方式做“微决定”。在每一个点都有可能犯错误。一些错误是简单的语法错误，我们的编译器或者测试会挑出来。但其他错误不会那么明显：设计缺陷，假设错误，需求误解，或者可能是选择了弱的数据结构。当我们单独写代码时，这些错误可能被忽视。接着我们开始在此基础上构建程序。当我们完成代码时，整个变化可能都是错的。评审结束后，假设评审者指出了这些问题，那么会有大量的返工。

　　但是有另一个程序员在旁边督视我们写代码，导致返工的那些初始错误就会在早期被指出。他们说，“等等！我觉得这可能不对……”我们一起讨论问题，然后纠正它。我们很快就回到正确的轨道上。

　　结对会更快

　　认为结对工作使那些程序员的产出减少了一倍，虽然看起来可能有道理。但上面的理由说明了为什么结对工作真的比标准的单独开发实践更快。但那只是其中一个原因，我们来看看其他原因。

　　独奏程序员会困住

　　我们单独工作时常常会被有些问题困住。有些问题解决相当棘手。我们想快，但是快容易混乱，尤其是当我们感到疲劳或烦躁的时候。我们被困住越久，越不可能看到问题。

　　如果你在某件事上困住了，把问题解释给其他人听会使问题解决方法显而易见。这样可行是因为当我们把我们的想法解释给第三方听的时候，我们会下意识把问题细化，并且为了确保他们跟得上，语速足够慢。有时候当我们这么做的时候，我们会发现当我们还在忙于描述问题的时候，解决方案奇迹般地出现在我们大脑里了。

　　结对和抱团的美在于你总是把问题解释给别人听。你在你大脑之外工作，爱冲到自己前面。结对不给你让大脑混乱的机会。

　　这些都不明显。如果明显的话，那么每个人在很早之前就已经结对。

　　为什么抵抗结对？

　　许多程序员都反对结对。一提到结对就会触发即时防御反应。给出结对带来的清晰好处，为什么有些人如此害怕它？

　　结对需要不懈地检查和批判。如果你不习惯的话，那么这是对系统的严重冲击。肾上腺素直接冲上来将我们放在高度戒备下。这击溃了我们的精力。对新手来说，结对编程耗尽精力。许多人在第一天结对编程后感到挫败一点也不惊讶。

　　那只是和你结对编程的第一个人。当你和下一个人结对编程的时候会怎样？你有听说过有人说他们只能和某些人结对编程吗？有多少程序员就有多少程序风格。我们一生都单独写代码，那我们真的只习惯于我们自己的代码。适应另一个人代码风格的能力需要时间和实践。适应许多不同代码风格的能力需要更多的时间。

　　有效结对

　　每个人都经历过初始的抵抗反应。解决办法就是坚持下去。我们尝试得更多，就更容易。

　　每一天变得越来越不无聊，直到我们能够每一天都结对编程。最终一旦你已经在足够长的时间里和足够多的人结对编程，你会意识到你可以和任何人在任何时间对任何事结对编程。

　　我们最终达到一个点，在这个点结对开发比单独开发产出更多。

　　这不是说结对编程从不让人觉得沮丧。我们都有心情不好的时候。但是那些日子应该最终变得越来越少，离我们越来越远。

　结对编程能替代代码评审吗？

　　对小而独立的团队来说，答案几乎肯定是可以代替。对更大的团队来说，尤其对整个企业来说，答案可能不那么明显。

　　与代码评审工具不同，结对编程在团队中形成了一个自然屏障使得代码讨论对外无影响。技术讨论不再发生在线上，他们发生在一个密闭空间。团队提升了他们自己做技术决策的自主权。任何外人-或许是其他团队的程序员，或者高级架构师无法阻碍这个团队的进度。

　　如果有外部利益相关者对这种变化感兴趣，比如确保代码遵循企业准则，那么代码评审仍然有用，但是优先级比以前低了。比如，在结对编程中你可能对你们创建的代码建一个pull请求，但是接下来立即自己合并它。那样的话这个pull请求还在那里用来让其他人跟进，但是开发却不需要等待代码合并。

  关于结对编程有很多要说的

　　在这篇文章里，相比于代码评审，我提出了结对编程的一些好处。除此还有其他好处—比如，结对编程是打破单干模式的一种非常好的方式。当然，还有许多关于结对编程值得了解的策略和技巧。我鼓励你通过同其他人分享知识当然还有强化训练来持续学习结对编程。