现代软件工程开发体验:结对编程
距现代软件工程开课已经3周,按照课程安排,在最近的9天中,我们进行了极限编程模式的体验: pairwork(结对编程,具体见链接),对象是在 academic search map上添加一些新特性。经过选择,最后partner与我选了在地图上加上conference信息。
按照标准的软件开发流程,在开始编码之前要做任务分析WBS(Work Breakdown Structure),就是把整体的工作细化到每一个细节,并且估计每个细节的工作量。下面是我们的WBS分析和实际结果的对比:
除去在开始工程之前,我们利用一天各自熟悉原有代码,结对编程的具体工作如下:
1、 将会议显示在地图上
|
预计完成时间
|
实际完成时间
|
获取会议基本信息
|
2小时
|
2小时
|
数据处理
|
1小时
|
2小时
|
Web API获取GPS信息
|
1小时
|
1小时
|
WCF通信服务传递数据
|
1小时
|
4小时
|
将会议显示在地图上
|
2小时
|
1小时
|
总计
|
7小时
|
10小时
|
所有的数据都在数据库中,而且需要用c#调用Sql server获取一些统计数据,而本身对数据库的组织形式并不熟悉,用去了不少的时间。另外在编写WCF服务过程中,出现了不能正常读取数据的问题,到处排错,最后才在网络上搜索才发现是WCF的默认配置是不支持跨域。
效果如下:
可以用年份筛选会议:
tooltip事件处理:
2、 界面设计及事件
|
预计完成时间
|
实际完成时间
|
设计会议展示界面
|
2小时
|
5小时
|
从学术搜索API获取数据
|
2小时
|
2小时
|
添加超链接及鼠标事件
|
3小时
|
5小时
|
总计
|
7小时
|
12小时
|
尽管使用silverlight做界面并不复杂,但是设计本身并没有一个标准,要获取一个相对满意的效果,还是需要许多时间。
效果展示:
4、 会议搜索
|
预计完成时间
|
实际完成时间
|
自动补全搜索框的实现
|
3小时
|
2小时
|
定位并显示
|
2小时
|
0.5小时
|
总计
|
5小时
|
2.5小时
|
由于我的partner唐傲有这方面的经验,极大地推进了整个工程的进度。
效果展示:
5、 Bug修护及任务上传
|
预计完成时间
|
实际完成时间
|
debug
|
5小时
|
8小时
|
任务上传
|
2小时
|
5小时
|
总计
|
7小时
|
13小时
|
一者,bug很多时候是没法预测的,二者,由于这个项目是20人的项目,在最后整合过程之中需要各方面的协调。还是超出了预计不少时间。举个例子,我们发现在搜索会议之后,再点击richtextbox中的hyperlink 系统会报错“stack overflow”,在经过不断的查错和翻阅资料,才发现这是silverlight本身的一个缺陷。最后,在经过仔细观察,发现只要在点击之前让richtextbox获得焦点就能避免错误。这样的一个错误让我们整整花了5个小时的时间。
谈过了具体的任务,再回头看一下本次的主题,结对编程。
不可否认,结对编程有着很多独有的优势。在工作中,多一个人参与同样的工作,就意味着有着更多的解决策略、检查测试 和想法,能够写出质量更高的代码。这样,也就避免了一个程序员因为一个小错误而不断地查看之前的代码,或者被一个不熟悉的问题卡住太多时间。另外,由于是两个人一起编程,相互督促,不断交流,不仅能够高效完成任务,而且能够相互学习,提高个人编程技巧。
当然,结对编程也并非适合所有的情况。以我们为例,再开始具体工作之前,由于都不熟悉原有的代码,此时与其进行着效率不高的交流,不如选择分开熟悉代码。另外,在后期工作中,我们也选择了分开差错。像即使两人共同努力效率也未必能提高的工作,结对编程就不容易显示出它的优势了。所以说,个人认为,是否使用结对编程也需要按照情况决定。
课程的另外一个工作是用“三明治”手法来评价自己的partner:作为才子牛人型人物,他的编程技术很少有同龄人能够比拟,但是,技术好并不代表预知所有情况,对于别人提出的可能性也是需要好好考虑的,错误的断言并不利于合作。不过,总的来说,他能够不计得失,知道自己武断之后,会马上改正,发现别人确实错了,也能够细心讲解,算得上是一个特别优秀的队友。
后记:记得邹老师说过,国外许多很好的工作都是由双人合作来实现的,比如Paul & Bill一起合作创办Microsoft,Page & Brin合作创办Google,以及yahoo!的创始人Jerry Yang & David Filo。中国人鲜有两人合作而最后取得不错成绩的,即使取得了成绩也容易闹不和,比如李政道和杨振宁。所以,更多的参与这样的合作确实是有益的,也是需要的。你是这样想的吗?