让我们一起探索分析结对编程成功的特征原因。
结对编程正在逐渐成为主流的编程方式。有着两年结对编程经验的我注意到，结对编程真的很棒，甚至可谓是神奇。但有时候，却又阻碍了我们的开发进程。我想探究这背后的原因，并搞清楚如何才能让结对编程一直发挥正能量的模式和方法。
我的结对经验
我认为先说明我自己的结对编程经验，有助于各位更好地评估以下的相关内容。我已经结对编程将近两年时间，就职过2家不同的公司。一家是咨询公司，我们开发了客户端应用程序。另一家是创业企业，开发了一个大型的SaaS产品。在这段时间，超过20个有着不同背景、性格、技能、经验和文化的开发人员和我结对编程。
边注：结对编程还有一个好处就是能让我与很多厉害的人共事，成为朋友。
有效结对的特征
回想我以往的结对经验，很多好的坏的体验似乎一下子历历在目，恍如昨天。我将此总结成为2*2的矩阵。
结对编程矩阵
定义
效率代沟
从我的观察角度来看，两个个体结对时相关性最强最具区别化的因素就是两者之间的效率。这些因素包括——他们以往各自的经验、领域知识、语言知识，等等。效率的另一种表达方式就是他们各自的输出潜力，包括速度和质量。为了讨论的方便，在该文中会把高效和低效的程序员分别形容为“高级开发人员”和“低级开发人员”。
利好
两个人结对编程比各自独立工作的期望优势。
效率差距小的结对编程
根据我的经验，效率差距小的结对编程普遍比差距大的要更好。原因或许是因为开发人员拥有的共性更多，交互时也更自在。在矩阵中列出的要点已经非常清楚。从本质上讲，差距小就意味着他们更能理解和相互尊重，愿意经常沟通，共同学习进步。这将是一场愉快又双赢的互动。
弱弱结对
我的观察结果告诉我，弱弱结对比强强结对的利好更多。为什么呢？大概是因为低级开发人员意见性不强，没有那么自负，更注重学习，而不是坚持自己是“正确”的。
你知道“新同学交友”效应吗。假设你还是一个孩子，在某个学年中途随你的家人搬迁到一个陌生的小镇上。这时候要是班上另外一个孩子大约也是在相同时间转学过来的，那么你们更容易成为朋友，因为你们的处境相同。结对编程也是如此。要是你们对某个新的应用/技术/语言/等等都不熟悉，那么之后的研究探索，由于处在平等的位置，你们不但更谈得来，而且合作解决问题的时候更契合。
两个低级开发人员结对的首要目标应该是学习。
强强结对
要是是两个高级开发人员结对编程，搭档起来会很难。因为每个程序员都是不同的，想法和意见也不尽相同。经验越丰富，越倾向于坚持自己的观点，并且还会越自大。而当其中一个人过于自大时，另一个人就只能当“应声虫”了。
更糟糕的是，要是两个人都很自大。此时他们会不断地争执争辩以在驳倒对方，于是两人之间的关系会紧张，充满敌意。我见过更糟糕的是，两个人甚至从头到尾一句话都不说，这显然是负面效应了。
良好的强强结对应该是相互尊重的。相互交流，辩论，讨论，还有规划，一起创造专业化的水平。强强联合导致的是雄厚的生产能力。
所以，两个高级开发人员结对的首要目标应该是产量。
强弱结对
这种结对安排往往发生在有新的开发人员加入公司，或切换到新的开发环境的时候。为新来的人员搭档一个高级开发人员，能让前者快速融入到团队中。但是要是选择的这个高级开发人员不合适，那么就有可能损害低级开发人员的信心和士气。
期望
首先领导人员必须明白人员安排的目的是尽可能快地推动开发进程。任何有着利害关系的人员也应该明白这个道理，这些人员包括其他开发人员、设计人员、QA等，尤其是高级开发人员。并且我们不应该给这个老带新的组合很多压力。
输出速度会变慢，因为生产的同时发生了指导。
指导
高级开发人员应该明白他们的角色是指导低级开发人员，而不是迅猛生产。
好的导师，愿意聆听和回答问题，观察并提出引导性的问题。
但是人的本性让我们很难做到如此。下面是一些要点：
不要告诉他们要打什么，要做什么，也不要直接就演示给他们看。不可否认这样会省事很多。但是你应该让他们看到自己所犯错误的后果，让他们自己去思考为什么这样不对，让他们自己纠正错误。允许他们问问题，然后用引导性的问题回答他们，让他们自己去探索。要是他们陷入了死胡同，就伸手拉一把。
我记得有一次我和一个完完全全的新手同事结对完成任务。因为那时压力真的很大，我选择了毫不留情地拖着他往前冲。虽然也经常道歉，但明显他的心情一直很糟糕。
好的导师应该具备充足的耐心和自信，积极促进低级开发人员的成长，而不是让他们成为人云亦云的应声虫。但是在这个领域，这样的导师实在是太少了。每个人都忙着完成自己的事情，又或者根本就没有教导他人的技能。下面这些问题或许有助于我们确定某人是否是一个好导师：
是否愿意与低级开发人员分享知识，帮助他们？是否嫉妒低级开发人员的技能，或是反感他们提出意见和见解？是否愿意牺牲自己的舒适力争团队的利好？
高级和低级开发人员结对的首要目标应该是指导和学习。
结论
正如我上面分析的那样，每种结对情况都是不一样的，关键是要承认他们的不同，了解如何使其能够更大地利好于团队。
祝编程快乐！