两个人的效率——记软件工程结对编程
作为程序员的你，不知道曾经是否尝试过这样一种开发模式：你有一个伙伴，你们坐在一起，并肩作战，面对着同一台显示器，使用着同一键盘，同一个鼠标，你们一起思考，一起分析，一起编程。如果你尝试过，那你可以继续读下去，看看我们是不是有同样的感受；如果你没有尝试过，那你更应该读下去，因为这篇文章将会带你体会这种编程模式，带你走进结对编程的世界。
下面，我就来讲讲我所经历的结对编程吧。
这次结对项目的名称为“学术会议的展示”，即在原有的微软学术地图的基础上，添加学术会议的信息及地理位置显示。这是一个不大不小的项目，两个人共同花了9天的时间，在完成基本功能并保证稳定性的同时，添加了一些华丽的界面元素，总的来讲，感觉不错。
因为是软件工程，所以我们要从工程的角度出发，在正式开始之前，要制定好自己的计划。对于一项工程，我们会有一个期望的结果，称之为Goal。为了实现这个Goal，我们会做许许多多的小工作，将这些小工作全部整合起来，就成了我们的项目。因此，我们首先要做的就是将项目细化为这样一个一个的小工作，这一步我们称之为WBS(Work Breakdown Structure)。
对于我们的项目——学术会议的展示，我们把他分成了三个部分，其中每个部分又分成数个小任务。
1、 将会议显示在地图上
2、 界面设计及事件
3、 会议搜索
以下是任务的细分及对任务完成的时间估计和实际完成时间。
1、 将会议显示在地图上
（1） 获取会议基本信息，如举办时间，全名，缩写，地点，学科方向等等。
估计完成时间：2小时 实际完成时间：2小时
（2） 数据处理，如计算会议的总发表论文数及被引用数，并对其排名
估计完成时间：1小时 实际完成时间：2小时
在这一步中，我们为了方便，并没有将所有数据都获取下来，然后离线处理，而是直接编写SQL语句实现。不过由于数据量还是太大，而且中途遇到过不少bug如数据重复问题，分学科统计问题，前前后后花费了我们两个小时的时间。
（3） 获取会议举办地点的经纬度
估计完成时间：1小时 实际完成时间：1小时
（4） 编写WCF通信服务将以上获取的数据从网站服务器传送给应用程序端
估计完成时间：1小时 实际完成时间：4小时
在这一步中我们终究还是低估了在编写Silverlight-WCF通信程序时可能遇到的各种问题，一个简简单单的跨域问题足足折腾了我俩四个小时时间，东测试西测试，没找到问题之所在，最终在网络上找到解决方案。
（5） 根据第二步所获取的会议排名，将会议显示在地图上
估计完成时间：2小时 实际完成时间：1小时
这一步作为最关键的一步，我们分配了两个小时，其实实现起来无非是按部就班，因此很快便完成了。
2、 界面设计及事件
（1） 设计会议展示界面
估计完成时间：2小时 实际完成时间：5小时
界面设计永远是没有最佳的，因为每个人的看法都是不一样的。在这一环节上，我与我的partner看法产生了分歧，最终采用的他的设计方法。事实证明做设计也是需要时间的，前后足足花费了我们5个小时，终于设计出了还看的过去的一个面板。
（2） 从微软学术搜索API获取所需数据并在所设计面板上显示出来
估计完成时间：2小时 实际完成时间：2小时
（3） 为界面添加超链接及鼠标事件
估计完成时间：3小时 实际完成时间：5小时
之前一直使用TextBlock或TextBox，界面难看且不灵活，于是打算自己设计界面。设计到一半，突然发现在Silverlight 4中richTextBox成为了系统组件，这为我们界面的显示提供了很大的便利，但也丰富了我们的想法，让我们在上面实现了更多的东西，超过了原有的预期的时间，但结果还是令人较为满意的。
3、 会议搜索
（1） 自动补全搜索框的实现
估计完成时间：1小时 实际完成时间：2小时
（2） 根据机构名定位到指定回忆举办地并显示其详细信息
估计完成时间：1小时 实际完成时间：0.5小时
以上就是我们详细工作的时间划分，但实际上我们更多的时间奉献给了讨论与修正bug以及最终与他人项目的合并工作。这是每一个人都可能会遇到的问题，怎么处理好这些问题也是对我们很大的考验。
上面介绍完了基本的任务，下面就是具体的实施结果了。
项目完成之前的界面，大家可以看这里：http://academic.research.microsoft.com/academicmap
我们的结果：
1、 查看
在左边栏中，可以选择Conference，然后我们便可以在地图上看到看学术会议。每一个圆点代表一个会议，根据这个会议总共发表的论文数，这个会议的原点会有不同的大小和不同的颜色。在左边可以通过学科方向和会议时间来筛选。
2、 界面
将鼠标移动到会议圆点上，我们可以看到详细的关于会议的信息，包括全名，缩写，年份，发表论文数及被引用数，举办城市等等信息。
当我们点击圆点以后，会弹出如下图所示的面板。这是会议信息展示的主界面，在这上面，我们一个划分额四个区域。
（1） 左上角为当前会议信息，当点击标题后，会打开新页面跳转到微软学术搜索相关会议的界面。
（2） 右上角为该会议所感兴趣的学科领域。
（3） 左下角为该会议在不同年份的信息，每一条信息都是建立在一个按钮之上，因此当鼠标点击时，在地图我们就会跳转到相应的位置及显示相关的信息。
（4） 右下角同样是该会议的相关信息，包括会议的主页，会议的前三条关键字，以及会议上最出名的三个作者（按被引用数排名）。每条信息都是一个超链接，当你点击时会打开新页面显示相关的信息。
3、 搜索
当进入会议视图后，我们会看到下面的搜索栏
下面输入我们想查询的关键字，以IEEE为例
搜索框自动补全了我们想要搜索的信息，当我们选中时，地图就会跳转到相应的会议举办地并显示如2.中所示的界面。
以上就是我们的结果，怎么样，从效果上看，还不错吧。
介绍完我们的项目，还是回到结对编程上来。这是我第一次体验这样的编程模式，这种模式到底好与不好，我只能说，因人而异吧。
不可否认，这样一种编程模式其好处是显而易见的。作为一个driver，在编程的同时，你总会想着你旁边还有一个人，这样你就会格外的认真，注意每一段代码的格式，按照统一的规范来写。作为一个navigator，你会时刻关注你旁边的人写的代码，思维在不停的运作，在写的同时进行着复审，在起到监督的同时也提高了代码质量，减少了复审所需要的时间，不用事后再去花大精力阅读代码，因为在写的时候你已经对代码非常了解了。每当一个人独自写程序时，如果任务不是那么的紧，我们很容易出现懈怠的情绪，这时我们可能会打开人人、微薄这种东西来打发消遣一下。当两个人共同工作时，你浪费你自己的时间不要紧，但你浪费他人的时间就说不过去了。
话说回来，世上人与人之间总是存在差异的，而不像机器那样由程序统一控制。当两个人的思维发生碰撞时，有时也许会融合并诞生出更好的想法，有时恐怕就会出现爆炸，令双方都不太愉快。如果让两个编程习惯及审美观差别极大的人结对完成一个项目，那可想这个过程会是多么糟糕，基本在争吵中度过，这样能够写好程序吗？当两个人的技术水平差别过大时，一人嫌另一人效率低，另一人则感觉被轻视，愈发懈怠，这有基本成了一个人的工作了，而且两人也不愉快。同时，这也许项目的选题相关，有些项目需要个人思考去解决问题，有些项目需要大家讨论来解决问题。有的人不喜欢旁边有人看着，有的人不喜欢总是看别人而自己不动手，这些都会成为结对编程的限制条件。因此，在结对编程前，我们应该确定合适的选题，并且两人不能太陌生，技术水平不能差别太大，要互相认可对方。有相同的认可，相同的兴趣，合适的选题，充分的热情，然后两人结对进行开发，这样才能发挥出结对编程应有的功效，不至于将大量时间浪费在无谓的争吵上。
结对编程真的能够带来1+1>2的效果吗？我认为这很大程度上取决于我们自己的规划，因为很多时候，我们需要自己独立的思考，去实现一些想法，并不需要两个人一天从早到晚一直坐在一起，面对着同一台显示器，一起思考，一起设计。
下面介绍一下我的队友林榕程。从汉堡包的角度出发——他是个技术能力非常强的人，有着强大的想象力，但是这些想象力往往会超出我们的实际能力，认为任何问题都很简单，从而造成一种心有余而力不足的景象，比较追求华丽，这与我所认可的简约美产生了分歧，不过，他确实是一个非常好的队友，追求卓越，为我们的项目做出了非常多的贡献，并且工作积极，很大程度上督促着我，同时也纠正了我的许多编程毛病，给了我很大帮助。
最后，来一张咱的合照：
照片上，我是一名driver，但更多的时候，我充当着一名navigator。
结对编程，你明白了吗？
