什么时候该采用结对编程？

　　结对编程是构建软件系统的一种有效方法。采用结对编程，带来的显著效益：

• 更好的想法——持续不断的头脑风暴、更大的知识库、在理解上有更少的差异、有更多的脑力解决设计问题；

• 更好的质量——更少的漏洞、想法的即时认证、始终如一的方法并更加遵守团队会议中的要求；

• 更全面的认识——经验共享与知识共享、对于为什么做、怎么做和做什么有更深入的理解；

• 更高的生产率——更好地集中精力及更高的工作强度、彼此促进并激励来达到最好的结果、更少的拖延和时间浪费；

• 更多乐趣——大多数人喜欢分小组工作并且共同解决有趣的问题。

　　极限编程的领导者坚持主张所有重大的进展都应成对进行。但是我们能说在所有情况下结对编程都是最好的方法吗？　　
　　程序员可以找到一些看似可行的方法来替代结对编程，这些方法不需要两个人始终都在一起工作：

• 想法——频繁的团队头脑风暴与短期结对（或团队）编程会议相结合，来解决最复杂的任务；

• 质量——测试人员与开发人员共事，一起编写自动化测试；

• 认知——频繁的讨论、代码复查、培训会议；

• 生产率——清晰的目的与务实的工作方法可以让你更集中精力、使方法更清晰并能带来更高的效率；

• 乐趣——密切合作与相互支持

　　什么时候结对编程是最有效的方法？

最主要的因素是技术与挑战相匹配。在独自编程中，如果技能和挑战能互相匹配，最高产的模式就是流模式（Flow）。结对编程添加了一个更有效的模式——指导模式（Coaching），它能够提高全队当前与未来任务的生产率。

　　成功的模式

　　1. 流模式（Flow）——两个程序员共同从事一个有趣又有挑战性的问题。他们会有不同的技术、遇到不同的挑战，但是它们都善于找到好的解决方法。例如，其中一个人可能是javascript专家，另一个人可能是强大的后台程序员。他们能够结合彼此的脑力、知识及经验来共同处理复杂的AJAX任务，从而创造出最好的解决方案。

　　2. 指导模式（Coaching）——老练的程序员在解决问题方面有经验和知识，可以与其他不能有效地独自解决问题的程序员分享。后来加入的程序员有足够的理论基础来理解这些解决方法和程序的实现。他会在学习中慢慢进步，成为更优秀的程序员。

　　失败的模式

　　3. 浪费专家时间（Wasting expert time）——问题太简单，以致专家的经验无指导意义。

　　4. 不知所措的新手（Overwhelmed novice）——问题太过复杂或者需要太多新知识，使程序员学不到任何有用的东西。

　　有疑问的模式

　　5. 两个专家共事一个易管理的任务——若两个程序员都了解如何实现任务并且之前都成功地解决过相似的问题，那么结对编程就没有太多的用处了。

　　6. 一个程序员处于流模式（Flow），另一个在一旁学习（Learning）——若另一个程序员时不时地打断他，并要求对一些基本的但与挑战性问题没有直接关系的事情做出解释，那么他很难专注于解决挑战性的问题。

　　7. 一个程序员处于流模式，另一个专注于指导（Coaching）——如果想让这种模式获得成功，指导者应该思想开放，避免指导过多，同时也可以给另一个程序员想出自己的（甚至是更好的）解决方法的机会。

　　此外，心理问题可能会导致结对编程的失败：

• 专家的威胁——遭到其他技术更高的程序员更具“威胁”的程序员，会担心自己被视为无能；
• 需要时间考虑——结对编程之前，程序员需要更多时间去考虑，但他往往在仔细考虑自己的想法之前就被强迫开始结对编程了；
• 宁可独自工作——内向的程序员喜欢独自工作(不合群的人)；
• 人员关系不融洽——程序员互相讨厌对方。

　　我们能使结对编程一直有效吗？

　　当然！把任务、技术和合作匹配起来。在两个生产方式中找到成对的——流（Flow）或者指导（Coaching）。若成对的程序员能够用他们自己的及从对方身上学到的技术来共同解决有趣的问题，那么这个团队将会是最高产的。

　　然而，结对编程应该是自由选择或及首选方法，但它不应是强制性的实践。就像你在这篇文章中所看到的，当结对编程不太有效的时候会产生一些模式和出现一些心理状况。

　　简而言之，结对编程应该是软件小组工具库中最有用的工具之一。要弄清楚什么时候及如何使用它。

　　结束语

　　你已经结对编程了么？如果你已经结了，欢迎在评论中和大家分享你的相关观点、经验和心得。