结对编程(Pair Programming)的实践、衍生和变体

为粗略一看，让两个人同时做一件事，比让他们各自做一件事，好像效率降低了一半。持这种看法的人很多并不了解软件开发本身，而是将编写代码看成单纯的打字。编写代码很多时候是一个思维的过程，对架构、设计的思考往往会占用很多时间，而不是单单地敲击键盘输入代码。而两个人一起的讨论，往往会比一个人更有效率的找出设计中的问题、得出最优架构。并且事实上，如果结对编程使用得当的话，并不会额外花费太多时间。犹他大学的劳瑞威廉姆斯(Laurie Williams)和罗伯特凯斯莱(Robert Kessler)的研究表明,在正确的实践下，完成同样的工作量，采用结对编程比单独编程仅仅多消耗15%的时间。

另一方面，成本并不能从仅仅从交付功能这个方面来计算。从更高的层面，一个软件的生命周期来观察，一个功能的成本其实可以用如下公式来计算：

功能成本 = 初次开发成本 + 重构成本 + Bug修复成本

结对编程的确在初次开发成本时消耗较大。然而它对重构成本和Bug修复成本的减少也是相当可观的。结对编程得出更优的架构设计，很多时候可以直接减少重构的成本，甚至直接消灭重构的需求。Bug修复成本更是如此，在软件或功能发布后修复一个Bug的成本，很多时候比起在初次开发阶段就发现和修复是大出很多倍的。比如顾客报告了一个Bug,通过客户支持(Customer Support)反馈回来。很多时候测试员需要花时间重新搭建Bug重现环境(Repro Envrionment),然后反复调试检查Bug在什么样的条件下会重现。随后程序员再修改代码，提交改动，进行代码审查，最后查入代码，将有新代码的产品或补丁发布。这一系列的成本花费牵涉到客户支持、测试员和程序员，涉及用户渠道和产品/补丁发布，远超开发时发现并改动的成本，更不用说给企业名誉和用户信心上带来的损失。如果Bug在软件或功能发布后较久时间才发现，可能原开发人员已经离职，新的开发人员要花很多额外时间熟悉相应代码和情景，才能进行修复，花费成本在上述基础上还会进一步增大。

以上可见，结对编程在初次开发成本上的额外消耗属于可控制范围，然而由于代码质量的提高，把问题防范于萌芽阶段，在重构成本和Bug修复成本上带来的节省却大量减少了全局的功能成本。再加上前面提到的对于经验传授、团队建设上的好处，总的来讲是远远利大于弊的。

结对编程的变体

乒乓编程(Ping-Pong Programming)：

乒乓编程是结对编程和测试驱动开发(TDD,Test Driven Development)结合的一种变体。具体做法是，结对编程中的一个程序员A先写单元测试，写好单元测试后运行确认不通过，然后换成另一个程序员B写具体功能代码，写好后再运行单元测试，确认这次通过，然后进行可能的代码重构，再写下一个功能的单元测试，写好后运行确认不通过，再换成程序员A来写相应的功能代码，以此类推，循环往复。你写了单元测试，我来实现具体代码，然后我再写单元测试，你来实现具体代码，这样的节奏就像打乒乓球一样你来我往，因此得名乒乓编程。这样的好处是单元测试和代码实现是不同的人实现，更能避免遗漏，同时两个人都同时参与了单元测试和具体实现，有利于测试驱动开发的实施。

强势结对编程(Strong Style Pair Programming)：

在结对编程时需要注意的一个问题是当领航员和驾驶员观点比较一致时，领航员容易找不出代码缺点来评论，逐渐丧失注意力，慢慢开始不专注，甚至开始查看自己手机短信等等。强势结对编程就是为了解决这个问题而产生的，它