两个人的效率——记软件工程结对编程

作为程序员的你,不知道曾经是否尝试过这样一种开发模式:你有一个伙伴,你们坐在一起,并肩作战,面对着同一台显示器,使用着同一键盘,同一个鼠标,你们一起思考,一起分析,一起编程。如果你尝试过,那你可以继续读下去,看看我们是不是有同样的感受;如果你没有尝试过,那你更应该读下去,因为这篇文章将会带你体会这种编程模式,带你走进结对编程的世界。

下面,我就来讲讲我所经历的结对编程吧。

这次结对项目的名称为“学术会议的展示”,即在原有的微软学术地图的基础上,添加学术会议的信息及地理位置显示。这是一个不大不小的项目,两个人共同花了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。

结对编程,你明白了吗?

posted @ 2012-01-06 14:08  xiangxiong  阅读(251)  评论(0编辑  收藏  举报