结对编程-神奇的力量

《敏捷软件开发实践》之结对编程

还记得入职之前，HR跟我说，你面试的时候是.NET，不过根据现在公司项目的状况，你很可能会去做Java，你愿意么？我想了想，从来没写过实际的Java项目啊，Hello world也是好几年之前了，这能行么？但是我又很想得到这份工作，然后就说：Let me try。就这样，我这么一个.NET程序员就跑到Java Team打酱油去了。现在，半年快过去了，做了半年的基于SH架构的Java开发。从开始的经常用”==”比较Long，使用首字母大写命名package，到现在我甚至可以解答其他团队成员的Spring问题。Ok，这一切都是拜结对编程所赐，多么神奇的力量。

ThoughtWorks是一家完全贯彻敏捷实践的公司，除了给那些想采用敏捷软件开发的公司提供咨询外，公司自身的所有项目也都是采用敏捷实践的，即我们通过亲身实践，并指导大家实践。在公司，几乎所有的代码都是结对编写出来的，刚开始我一直质疑这种做法：用两个人去开发一个功能，这不是浪费客户的钱么？因为刚开始的时候自己挺小白，一直是作为一个旁观者（在结对编程里这个旁观者称为observer或navigator，不过这里很显然，我不是一个称职的navigator）看别人写代码（在结对编程里，这个写代码的人称为driver），所以也不好提出质疑，就想看看结对编程真的如书上所说那么神奇么。

经过一个迭代之后（我们项目的迭代周期是两周；当然，你可以选任何合适的周期，不过不要太长，不然难以更快的获得反馈，也不要太短，那样会来不及收集到有效的反馈），还记得在迭代回顾会议（Scrum方法里每个迭代结束会开一次回顾会议，对过去一个迭代里做的好与不好的方面做一个总结，也称之为retro，回顾会议的方式有多种多样，比如我们经常采用的是，总结过去一个迭代，做的好的，做的不好的，有疑问的）里，Tech Leader贴了一张Well纸条：Joy（我）开始独自driven一个user story了。是的，经过两周的结对，我也能driven一个user story了。我很惊奇我进步的很快，也感叹结对编程太神奇了。当初的疑问也一一打消：

结对编程可以传递知识，打破知识壁垒

在传统的开发方法中，每个模块可能是由专人负责，当这个人因为各种原因，比如离职，比如请假而缺席时，其他人往往因为缺少上下文知识难以甚至不能接受他的工作，这样甚至会阻碍其他相关功能的开发。而且如果此人离职还需要花费很长时间进行交接，在交接期间两个人都不能干其他工作。而结对编程是一个功能由两个人共同完成的，而且在这个功能完成期间甚至进行了好几次结对伙伴交换，很多人都会对一个功能具有相关知识，所以不会形成知识的壁垒。

结对编程可以培训新员工

传统的做法是，如果有新的项目成员进来时要么抛给一堆文档，让其“研究”，然后告诉他有什么问题可以来问，但是大部分新人即使不懂也不会去询问，而且这些文档常常还过时，与现在的项目早已不同步。要么就派出一个老员工对其进行培训，这样不断耽误了老员工的工作，而且这种培训效果真的不怎么样，因为空口说教效果本来就不好。而结对编程的方式，虽然会拖慢一个老员工的工作效率，但新员工却能很快熟悉项目的结构，代码的规范，有的老员工在写一段代码时，都会说自己的想法，然后写，还不断的问你懂不懂，理解了么（这里要感谢当初不断的停下来讲解代码思路的前辈们）。你有任何不懂的也可以随时打断你的结对伙伴的工作（我就是这样学到了Intellij Idea所有的快捷键）。

结对编程可以提高工作效率

其实，我很不想写这一条，因为这一条的画外音是：结对编程是资本家剥削劳动人民的工具。

在传统的开发方法中，往往每个人使用一台机器，呆在自己的小隔间里，干着自己的工作，一天八个小时，你可以写写代码，上上博客，聊聊QQ，看看新闻。其实有效工作时间也许就4个小时，但是在结对编程里，因为两个人公用一台机器，你不可能堂而皇之的当着你的同事的面逍遥自在的聊着QQ（如果你有这魄力，我实在佩服得很）。所以每个人的工作效率都非常高，所以两个人做一件事，并没有浪费客户钱（其实，还为公司节省了一批机器的费用，嗯~~）。

结对编程会降低缺陷率

由于惯性思维，程序员常常写出有bug的代码而不觉，而结对编程会有四双眼睛盯着当前的代码，你在写的同时，你的伙伴会盯着你的代码，寻找可以表现的机会，一有机会他就会无情的剥夺你使用键盘的权利。而且，当你在专心致志的编写当前的代码时，你的结对伙伴还会基于你当前的代码思考未来的想法，这样既能够让你能关注现在，还能思考未来的进化。有一种结对编程由一个人编写测试，然后由另外一个人来实现（后面会介绍），这样就会避免你的惯性思维，习惯的绕过自己代码的bug。

结对编程可以提高重构的质量

人们往往对自己的代码敝帚自珍，即使那段代码不够好，他也会找出各种各样的理由阻止自己或别人抛弃它，舍不得扔掉。但是，别人却不会在意你写的代码，如果不好，他会毫不留情的重构。

比如在我们的团队，每天早晨我们会进行Code Review，代码的开发人员向其他成员讲解他昨天开发的代码，其他人会对代码发表意见，如果是小的意见代码的开发人员会用便笺记录下来，待会儿立马修改，如果是比较大的重构意见，代码的开发人员就会说：嗯，我觉得你说的很有道理，今天我和你结对重构这块儿吧。就这样他们就结对了，并且可以对这一块进行更深入的探讨，或许早晨那次重构的意见并不成熟，或许他们进行了一次深入的重构。因为新人加入会带来新的思维，而老的开发人员也没离去，可以快速的熟悉上下文。

在公司中还有这种情况，比如我们要添加一个新的功能，但添加新功能涉及的一块代码并不是我自己编写的，我可能不太熟悉，那么我们就会找到开始开发这块代码的人说：我今天想开发XX功能，但是可能会涉及YY功能，YY功能以前是你开发的，我们今天结对开发XX吧。

结对编程可以增进沟通

XP的四个基本原则之首就是沟通，实际的软件项目中，有很多也是因为低效的沟通导致项目失败，沟通不良造成对需求的误解，沟通不好造成对架构的误解比比皆是。在我们的项目中，整天嗡嗡之声不绝于耳，都是结对的人在某一个问题上进行讨论，有的时候结对的两个人谁都说服不了谁的时候，说明两个都对这个事儿存在“误解”，这是我们就会邀请更多的团队成员进行讨论。知识就是在这个讨论过程中不断的传递，越来越透彻。

结对编程的优点太多了，这里只是列举了最典型的一些情况。其实结对编程只是一个比较笼统的说法，结对编程还有各种各样的形式，根据不同的人和不同的团队以及不同的项目可以采取不同的结对方式，下面会列举一些常见的结对方式：

Ping-pong

这也是我们公司最常采用的一种结对方式：

Partner A:编写一个失败的测试

Partner B:尽快让测试通过

Partner A:编写下一个测试

……

或者

Partner A:编写一个失败的测试

Partner B:尽快让测试通过

Partner B:编写下一个测试

……

前一种方式一个人编写测试，一个人编写实现，不过这种角色也会过一会儿交换一次，第二种方式，两种角色会频繁交换。

可以看出，Ping-pong这种结对方式是以TDD为基础的（那是极限编程的另一种实践），所以如果你的Team如果已经采用了TDD的开发方法倒可以尝试一下。经过我这段时间的实践发现，这种方式，往往是第一个测试很难编写，如果开好头之后就容易得多了，所以对编写测试的人要求往往高一些。还有一点是，编写实现的人一定要编写刚刚好的代码就够了，不要人家编写一个测试，你一下子就将所有的功能全部实现了，有的时候你甚至可以故意去欺骗测试，来挑战你的结对伙伴，比如当测试中有这样的断言时assertEquals(5,expected)，你就故意返回一个硬编码5，这样就逼迫编写测试的人写出更多更有效的测试。

Keyboard/mouse

顾名思义，这种方式就是一个人控制鼠标，一个人控制键盘。当鼠标点击到哪里，控制键盘的人就在哪里输入。

Coach

这种方式是让一个初级的开发人员控制键盘编写，一个资深的开发人员坐在后面观察并指导。

实际上结对编程的方式也不止这几种，但手头上也没有资料，有知道的人可以给补充补充~~

 

弊端

当然，结对编程并不是银弹，并不是只有优点没有任何缺点。首先，很多开发人员难以接受这种方式，大部分习惯独自的思考，独自的解决问题，而且这还要让自己所有的代码暴露在别人的眼皮底下，这是对传统思维的挑战。对于管理层来说也难以接受，让两个人干同一个工作，傻帽儿也知道这是浪费啊，不过让他们看到结对编程带来真正的效益的时候他们往往会采纳。

 

嗯，结对编程的意思是：如果代码评审是好的，那么我们会始终评审代码。这也是极限编程中极限二字的含义，将一切认为好的东西做到极致。