编者按：原文作者Andriy Solovey从事软件开发已有15年，做过开发人员、软件经理和系统架构师。关注构建优质、可靠和可用的软件。
结对编程是构建软件系统的一种有效方法。采用结对编程，带来的显著效益：
- 更好的想法——持续不断的头脑风暴、更大的知识库、在理解上有更少的差异、有更多的脑力解决设计问题；
- 更好的质量——更少的漏洞、想法的即时认证、始终如一的方法并更加遵守团队会议中的要求；
- 更全面的认识——经验共享与知识共享、对于为什么做、怎么做和做什么有更深入的理解；
- 更高的生产率——更好地集中精力及更高的工作强度、彼此促进并激励来达到最好的结果、更少的拖延和时间浪费；
- 更多乐趣——大多数人喜欢分小组工作并且共同解决有趣的问题。
极限编程的领导者坚持主张所有重大的进展都应成对进行。但是我们能说在所有情况下结对编程都是最好的方法吗？
程序员可以找到一些看似可行的方法来替代结对编程，这些方法不需要两个人始终都在一起工作：
- 想法——频繁的团队头脑风暴与短期结对（或团队）编程会议相结合，来解决最复杂的任务；
- 质量——测试人员与开发人员共事，一起编写自动化测试；
- 认知——频繁的讨论、代码复查、培训会议；
- 生产率——清晰的目的与务实的工作方法可以让你更集中精力、使方法更清晰并能带来更高的效率；
- 乐趣——密切合作与相互支持
什么时候结对编程是最有效的方法？
最主要的因素是技术与挑战相匹配。在独自编程中，如果技能和挑战能互相匹配，最高产的模式就是流模式（Flow）。结对编程添加了一个更有效的模式——指导模式（Coaching），它能够提高全队当前与未来任务的生产率。
成功的模式
1.流模式（Flow）——两个程序员共同从事一个有趣又有挑战性的问题。他们会有不同的技术、遇到不同的挑战，但是它们都善于找到好的解决方法。例
如，其中一个人可能是javascript专家，另一个人可能是强大的后台程序员。他们能够结合彼此的脑力、知识及经验来共同处理复杂的AJAX任务，
从而创造出最好的解决方案。
2.指导模式（Coaching）——老练的程序员在解决问题方面有经验和知识，可以与其他不能有效地独自解决问题的程序员分享。后来加入的程序员有足够的理论基础来理解这些解决方法和程序的实现。他会在学习中慢慢进步，成为更优秀的程序员。
失败的模式
3.浪费专家时间（Wasting expert time）——问题太简单，以致专家的经验无指导意义。
4.不知所措的新手（Overwhelmed novice）——问题太过复杂或者需要太多新知识，使程序员学不到任何有用的东西。
有疑问的模式
5.两个专家共事一个易管理的任务——若两个程序员都了解如何实现任务并且之前都成功地解决过相似的问题，那么结对编程就没有太多的用处了。
6.一个程序员处于流模式（Flow），另一个在一旁学习（Learning）——若另一个程序员时不时地打断他，并要求对一些基本的但与挑战性问题没有直接关系的事情做出解释，那么他很难专注于解决挑战性的问题。
7.一个程序员处于流模式，另一个专注于指导（Coaching）——如果想让这种模式获得成功，指导者应该思想开放，避免指导过多，同时也可以给另一个程序员想出自己的（甚至是更好的）解决方法的机会。
此外，心理问题可能会导致结对编程的失败：
- 专家的威胁——遭到其他技术更高的程序员更具“威胁”的程序员，会担心自己被视为无能；
- 需要时间考虑——结对编程之前，程序员需要更多时间去考虑，但他往往在仔细考虑自己的想法之前就被强迫开始结对编程了；
- 宁可独自工作——内向的程序员喜欢独自工作(不合群的人)；
- 人员关系不融洽——程序员互相讨厌对方。
我们能使结对编程一直有效吗？
当然！把任务、技术和合作匹配起来。在两个生产方式中找到成对的——流（Flow）或者指导（Coaching）。若成对的程序员能够用他们自己的及从对方身上学到的技术来共同解决有趣的问题，那么这个团队将会是最高产的。
然而，结对编程应该是自由选择或及首选方法，但它不应是强制性的实践。就像你在这篇文章中所看到的，当结对编程不太有效的时候会产生一些模式和出现一些心理状况。
简而言之，结对编程应该是软件小组工具库中最有用的工具之一。要弄清楚什么时候及如何使用它。
结束语
你已经结对编程了么？如果你已经结了，欢迎在评论中和大家分享你的相关观点、经验和心得。
聊聊结对编程
在敏捷软件开发的各种实践中，结 对编程（Pair Programming，下文简称Pair）是特别有争议的。Pair有一个特点，那就是还没有进行过任何Pair实践前，你很可能对它已经有了“喜欢” 或者是“讨厌”的印象。如果有人问你，你喜欢持续集成吗？你多半会回答：不是很肯定，需要试试看。但如果有人问你，你喜欢Pair吗？我猜你会马上给予明 确的肯定或否定的回答。喜欢它的人会觉得好处多多而成本低低，不喜欢它的人会觉得讨厌得难以想象。喜欢与不喜欢都可以形成强大的阵营，两边都不乏重量级的 高手。Pair的优点说起来都很明显，比如：快速反馈，更好的设计，甚至更高的效率等等。但据我了解，不喜欢Pair的人基本上都承认Pair有优点，只 是他们通常会提出反对意见，比如：Pair要求两个人协调一致，每个人的作息时间需要同步，如果一个人请假，那另一个人怎么办？等待就太浪费时间了，如果 自己一个人做那就不是Pair了；或者也有很多人感觉到Pair的时候特别累，不像一个人工作那样自主，写一小时程序，上十分钟微博，两个人同一台电脑工 作自由就小多了。
我所在的公司是Pair的实践者，对于喜欢Pair或者不喜欢Pair的各种原因和心态我都有切身的体 会。在实践中，我们并没有完全一成不变地照搬Kent Beck在《Extreme Programming Explained》书中所定义的Pair模式（Driver Observer模式）。因为，Pair毕竟是一种实践方法，可以供我们在软件开发中参考，而不必像对待科学理论一样教条。另外，我认为要让这种实践方法 发挥它的威力，消除人们心中的讨厌甚至是恐惧情绪是首先要解决的问题，甚至我们可以为此修改一些Pair的传统做法。下面我先来大致描述一下我们的实践模 式（Owner Supporter模式）：
<阶段1-Pair形成>
Team 在接到一个大的Story后经过讨论并分解任务形成一个个粒度适中的Task。Task的粒度一般在几小时到一两天这种级别，涉及的代码规模大约是几行到 几个类/函数。每一个Task，都有一个Owner作为责任人，这是和传统单兵开发模式相同的。不过，Owner的产生一般不是由ScrumMaster 来分配指定，而是Team成员自发地去协商选择适当的任务。Owner拿到Task以后会从Team中找一个Supporter，形成Pair。这也是一 个自发协商过程，没有强制指定，也没有固定的搭档，这样形成的Pair一般会是配合最默契也最适合相应Task的。
<阶段2-初始讨论>
Pair 形成以后， 一般是由Owner先分析需求，设计测试，并初步分析思考得出初步的设计思路。这时，Supporter可以暂时先不了解需求。然后Owner邀请 Supporter一起，向Supporter介绍需求和自己的设计思路。Supporter这时需要帮助Owner理解需求，设计测试，对设计方案提出 反馈意见，或者提出新的设计。讨论的理想结果是两人达成一致形成最终的设计方案，如果两人分歧严重不能达成一致则需要更多的人参与，比如：可以举行一个小 型的技术讨论会议把讨论扩大到整个Team。
<阶段3-具体实现>
<阶段4-Review>
具 体实现完成以后，Owner又会邀请Supporter来review自己的工作。这个过程一般是借助版本控制工具对比代码改动，Supporter从实 现的角度来审查实现是否符合设计，有没有可以直接观察到的bug和潜在的问题。如果发现问题并讨论确认，Owner再做相应的改动，再Review。最终 Supporter不能review出问题了，Owner提交代码。
<阶段5-维护>
虽 然经过了讨论和review， 但在后续的测试或者上线后仍然会陆续发现问题，这时就涉及到维护工作。维护工作依然是由Owner牵头，分析log，看代码，重现，修正；但 是，Owner也可以随时邀请Supporter参与分析讨论，至少在Owner准备修改原先的代码时应该要告诉Supporter“原先我们某个地方没 有考虑周全，有什么什么问题，我打算怎么怎么改动”。这个过程好像又回到了阶段2，然后阶段3，阶段4 ... 开发中还有一种可能是，原先的Supporter或Owner已经不在Team内了，这时就需要加入一个新人形成Pair，有经验的人应该向自己的新搭档 介绍Task的相关背景。当然，还很有可能碰到根本没有熟悉该模块的人了，这时就必须形成一个新的Pair，把维护作为一项新Task。
上面基本上就是我们的Pair实践模式了。这种模式基本上还是保留了大部分经典Pair模式的要点，主要的区别在于：
1.
把Pair的形成纳入Scrum框架的任务划分过程。Scrum通常会在Sprint的计划会议中将大的User
Story拆分成许多小的Task，每个Task一般对应几小时到一两天的工作量。Task列表出来以后，Team自发协商每个Task形成一个
Pair，整个过程一般没有管理者的直接干预。Story的背景需要Team中的每个人都了解，Task的细节由Pair负责。Pair的效果通常也依赖
于Task的合理划分。
2.
避免全程Pair。因为，全程Pair在实践和心理上会遇到很多问题，比如：时间同步问题，并行工作问题，不自在感问题。避免全程Pair可以使得
Owner和Supporter的时间安排更加灵活，增加并行性，减少不自在感。大部分不喜欢Pair的人基本上都是尤其不喜欢全程Pair，所以这项改
动对于吸引更多的人采用Pair具有重要的意义。
3. 区分Owner和Supporter的职责。经典Pair模式中Driver和Observer角色是随时交换的，也就是说对于一个Task来讲两个人的 职责是相同的，这样可以减小每一个人的压力，但又容易造成缺乏责任感。Owner Supporter模式是单兵模式和经典Pair模式之间的一种妥协，试图在责任和压力之间找到一种平衡。Owner是驱动整个过程的主导，并且是主要的 具体实现者；Supporter以辅助为主，在讨论和review的时候可以站在不同的角度帮助Owner。Supporter并非没有责任，熟悉Task的所有细节是Supporter的责任。当Owner由于请假或忙于其他事物时，Supporter应该立即可以代替Owner处理Task的实现或维护。如果Supporter做不到完全的backup，这就是Supporter的失职，在整个Team和领导的心中应该有这样的认识。
最后，除了显而易见的“引入反馈，提高质量”等很“官方”的优点外，我从管理者和开发人员的角度分别总结一下Owner Supporter模式的“不为人知”却真正很有价值的优点。
管理者角度：
1. 应对人员变动：每个模块至少两个人熟悉，这样在有人请假的时候都有backup，不会造成严重的耽误工作进度。如果有人要离职，交接工作通常也会非常轻 松，几乎没有什么需要特别交接的。很多项目都缺乏文档，只有实现的人知道怎么回事，而即使有文档也总有不清楚的地方，所以留住熟悉的人就是留下了活文档。
2. 增加对质量的信心：相比单兵作战模式，即使是不懂技术的管理者，Pair也可以自然地增加他们对于软件质量的信心，毕竟“三个臭皮匠顶个诸葛亮”。另外， 需要特别提到的是安全性问题。我曾经听说过一个电信计费项目，一个开发人员故意留了一个漏洞，把钱自动打入自己的银行卡，最终为公司带来了麻烦。如果采用 Pair方式，这种情况就不那么容易发生。
3. 过程透明，增加反馈：信息反馈是敏捷方法的重要支柱，而及时准确的反馈又依赖于过程的透明。在Pair模式下，整个软件开发过程是透明的，开发人员不容易 有意或无意的隐藏项目的细节和风险，因而管理者更容易获得及时准确的反馈。另外，对于同一个事物，不同的人也会有不同的看法，这是很正常的现象。比如，在 对问题进行估计时一个人乐观，一个人悲观，这时管理层可以同时参考他们的意见，对问题掌握得更加全面。
4. 代替培训：相比传统课程或讲座式培训，Pair能让新员工更快地适应项目。Pair方法也和一些公司采用的导师制有明显的区别。导师制更强调师傅带徒弟， 而Pair则不然。在实践中，我们更鼓励基础比较好的新员工多做Owner，老员工作为Supporter支持；只对基础比较差的新员工先从 Supporter做起，然后逐步过渡到Owner。这样做是因为新员工一般积极性比较高，适合承担更多的具体工作，而老员工则应该避免重复劳动，而是以 辅助和指导为主。另外，新员工也可能带来一些新的思想、方法和技能，这些反而是老员工应该学习的。
开发人员角度：
1. 分担压力，增加默契：Task依然具有明确的责任人，但Supporter可以分担Owner的压力，即使是Team内的技术高手有一个人做backup也是有益的。有人讨论有人支持更容易达到良好的工作效果，而大家相互Support也可以让团队更加默契。
2. 消除经典Pair的不自在感： Owner Supporter模式与经典Pair的Driver Observer模式相比更少存在不自在感，因为整个过程是Owner主导的，他有更多的自由安排什么时候讨论，什么时候独立工作。
3. 分享知识和技能：在Pair的过程中Owner和Supporter会自然地相互传播和分享知识和技能，有助于学习提高。
4. 培养组织能力和表达能力： Owner相当于一个微型团队的leader，在Pair过程中可以锻炼组织能力和表达能力。这个过程可以让一些不善于交流和组织的技术人员逐渐改善交流和组织能力。
Owner Supporter模式在我们的实践中收到了良好的效果，而且成本很低，值得推荐！