好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

现代软件工程开发体验:结对编程

现代软件工程开发体验:结对编程

  距现代软件工程开课已经 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 唐傲。

              课程的另外一个工作是用“三明治”手法来评价自己的 partner :作为才子牛人型人物,他的编程技术很少有同龄人能够比拟,但是,技术好并不代表预知所有情况,对于别人提出的可能性也是需要好好考虑的,错误的断言并不利于合作。不过,总的来说,他能够不计得失,知道自己武断之后,会马上改正,发现别人确实错了,也能够细心讲解,算得上是一个特别优秀的队友。
后记:记得邹老师说过,国外许多很好的工作都是由双人合作来实现的,比如 Paul & Bill 一起合作创办 Microsoft , Page & Brin 合作创办 Google ,以及 yahoo !的创始人 Jerry Yang & David Filo 。中国人鲜有两人合作而最后取得不错成绩的,即使取得了成绩也容易闹不和,比如李政道和杨振宁。所以,更多的参与这样的合作确实是有益的,也是需要的。你是这样想的吗?

经过了两周轰轰烈烈的工作,我们的 Pair work 终于大功告成了!回首这两周,时间虽然不长,但可谓历尽坎坷,一路走来,有太多的酸甜苦辣,有太多的欢笑痛苦,不总结一下实在可惜,下面请听我一一道来!

( 1 )题目

学术搜索机构位置坐标(经纬度)检测和校正

( 2 )团队成员( USTC “明”系列)

李明磊,科大——微软联合培养实验班学生,来自 0823 电子科学与技术系

谭明慧,科大——微软联合培养实验班学生,来自 0810 自动化系

( 3 )我们的目标

鉴于目前学术搜索数据库里面机构的位置坐标覆盖率并不高(在所有的 20667 个组织中,有 19537 个组织在查询范围之列,其中仅有 10678 个组织在数据库中有原始地址坐标信息,所占比例为 54.6553% ,还有部分信息不准确),这些数据大多来自 Bing maps  或是人工标注,我们的目标是从其他的数据来源获取位置信息,在检查准确率后,对原始数据进行补全和修正。

( 4 )项目分解

我们的工作分为如下几个部分:

A ) Excel  接口(导出 name 信息,导入查询后返回的地址信息)

B )发送请求 (Webclient)

C )   获取地址信息 (Google API and Yahoo API)

D )  XML  分析

E )数据处理 (Google , Yahoo 和原始数据的比对 )

( 5 )预计时间花费和实际时间花费

 

分项名称

预计时间花费

实际时间花费

Excel 接口

1 个晚上

3 个小时

得到地址信息

3 天

2 天

JSON 和 XML 分析

3 个小时

1 天

数据处理

2 天

1 天

具体说明如下:

A )刚接手任务第一个要处理的就是 Excel 表格,对怎样在 C# 中打开 Excel ,我们在开始阶段完全没有思路,最初只是比较盲目地在网上查找,可以说对通过怎样的方式解决这个问题完全没有概念,其实,等到真正找到 Office Excel 的接口,问题就迎刃而解了,我们只需要按照其标准的固定格式完成初始化和一般存取就可以了。此阶段的主要时间花费在查找资料上。

B )由于数据库的原始数据来源是 Bing Maps ,所以我们决定放弃 Bing API ,而改为用 Google API  和  Yahoo API ,与 Excel 接口处遇到的问题大同小异,我们在此前对 API 可以用一无所知来形容,在 Google 的众多 API 应用中怎样找到最合适的那一个是耽误最多时间的过程,在找到 Google 适用的 API 后,我们很快用同样的方法找到了最合适的 Yahoo API 。此项工作在难度上比预想要小,但在资料的获取上比预计要难!同时由于 Google API  有每天访问 2500 次的限制,我们也使用了代理来解决这个问题。

C )我们在最初选择用 JSON 型数据,但在按照标准形式进行解析时,经常会遇到 security problems ,我们在周六下午调了一个下午还是没有什么起色,最终只好放弃 JSON 而改投 XML 。而对于返回的 XML 行文件, Yahoo (多为层层嵌套)的结构性要比 Google (多为并列关系)的结构性明确,所以 Yahoo 解析的进程要比 Google 快很多。

D )看到得到的几万条数据我们感到很兴奋,但是从第二组传来的消息提醒我们:要检查我们得到的信息是否准确,不准确的信息是没有任何意义的,因此,我们又投入了一天的时间进行数据处理,通过对不同数据来源的比对将数据划分可信度级别,并对原始数据提供改善意见。

( 6 )我们得到的结果

A )直接获得数据

1 )在 19537 ( parents ID = 0 )个待查数据中,有 10678 个有原始经纬度信息,所占比例 54.6553%

2 )在 19537 ( parents ID = 0 )个待查数据中,有 12397 个有 Google API 经纬度信息,所占比例 63.4539%

3 )在 19537 ( parents ID = 0 )个待查数据中,有 19170 个有 Yahoo API 经纬度信息,所占比例 98.1215%

B ) Yahoo  和  Google 数据比较

尽管 Yahoo 数据的覆盖率很高,但是准确率没有保证,所以我们通过对比 Yahoo 和 Google 的数据对信息的准确度划分层级,在 API 返回的数据中, Google 返回 12397 个地址信息, Yahoo 返回 19170 个地址信息,其中有 12309 个组织同时具有 Google 和 Yahoo 两个返回值, Yahoo 和 Google 的数据以以上数据为比对对象。

1 ) Google 中有一项是 viewport ,分别有 southwest 和 northeast 两组信息,分别确定了可是区域的西南角和东北角,我们将这两组信息所确定的长方形的边作为区域信息,若返回的 Yahoo location 在此范围之内,可认为 Google 和 Yahoo 返回的信息是一致的,该数据是一级可信的。一级可信数据共有 4122 个,所占比例 33.4877% (在 12309 个数据中),该数据的精度在公里量级。

2 )将 Google 返回的 Area Level 1  与 Yahoo 返回的 State 信息进行比对,如果一致,该数据是二级可信的。二级可信数据共有 4273 个,所占比例 38.3703% (在 12309 个数据中),该数据的精度在州,省级。

3 )将 Google 返回的 Country Short 和 Yahoo 返回的 Country Code 信息进行比对,如果一致,该数据是三级可信的。三级可信数据共有 12271 个,所占比例为 99.6913% (在 12309 个数据中),该数据的精度在国家级。

C )原始数据和 Google 数据比较

在 API 返回的数据中, Google 返回 12397 个地址信息,原始数据有 10678 个地址信息,其中有 7902 个组织同时具有 Google 和原始两组数据, Google 和原始数据以以上数据为比对对象。

与 Yahoo 一级可信数据的产生原理相似,如果原始数据在 Google viewport 的范围之内,则认为该原始数据是一级可信的。一级可信数据共有 4633 个,所占比例 58.6307% (在 7902 个数据中),该数据的精度在公里量级。

D )在以上等级划分中我们可以看出, Google-Yahoo 一级可信数据和 Google- 原始一级可信数据的精度都是很高的,因此我们将两组数据进行融合,对某个存在一级可信数据的组织,若只有 Google- 原始一级可信数据,则保留;若只有 Google-Yahoo 一级可信数据,则替换为 Google-Yahoo 一级可信数据,若都存在,则保留原始数据不变。经过以上这般努力,有 1678 个组织的经纬度 信 息 可以用一级可信的数据进行 补充或修正,经过 随机测试 (在唐傲同学的 帮助下),以上的数据是非常准确的。

( 7 )小组成员工作照

( 8 )合作的收获和意义

虽然我和李明磊在大一时做了一年的同学,但是在此次合作之前并没有共同完成过任何工作,在此次合作的过程的,我们收获了很多。

首先,两个人在一起可以集思广益,我们都是没有过丰富编程经验的菜鸟,比起其他组的轻车熟路,我们在合作是没有很明确的章法。有时候一个人灵光一现的确就是个很好的思路,我们对工程的搭建也就建立在这一个个转瞬即逝的小点子中,这是两个人合作的第一个优势。

其次,两个人面对同一台电脑一起编程可以及时的找到问题,由于每个人的编程习惯不一致,容易犯的错误也不一致,因此在编程中出现的自己不易察觉的问题往往能被同伴及时发现。所以在两个人同时编程的过程中,我们基本没有在编译中出现问题。

此外,两个人面对同一工程的态度也很重要,作为两个非计算机专业的学生,我们在这次 pair work 中可以说没有明显的优势,也许其他同学手到擒来的很多工作,需要我们付出很多的艰辛和努力。也正是基于以上原因,我们在第一天就达成了共识:我们真正在意的不是成绩,而是能够学要了多少东西。作为两张白纸,我们有更大的空间可以书写!我们的成果不一定是最好的,那我们一定是收获最多的几个人之一!

最后,也是最重要的,两个人在配合时的相互扶持和鼓励是非常重要的!由于之前没有编程经验,我们组可谓一穷二白,因此在开始阶段遇到了比较大的挑战,完全没有头绪的我们,进展比绝大多数组都慢。在我看来,面儿上很淡定的两个人,心里却都急得像热锅上的蚂蚁,但我们谁都不愿意让自己的紧张情绪给对方带来压力。这时候,我们在每取得一小步进步的时候都会相互鼓励,那一段日子, lync 我们两个人的谈话记录中“加油!”,“ Good job !”是最常见的词语,正是这些看似不起眼的鼓励,让我们以十足的勇气冲破了一个又一个难关和屏障,顺利地完成了任务!

当然,在合作过程中也有一些困难,比如,我们在微软不属于一个组,而且两个人在组里都有一定的工作要完成,因此工作的计划和安排也不一致,但是既然是要共同完成的 pair work ,我们多少要“就合”对方的空闲时间,因此,合作有时候会比一个人完成工作耽误时间,但是比起以上的那些优势,浪费的这点儿时间就不值一提了!

( 9 )对同伴的评价

我和李明磊的合作过程是融洽而愉快的!他是个很细心的人!不知不觉两周过去了,我已经记不得有多少次在晚上 11 点多我们还在讨论问题时,他会体贴地说一句:时间不早了,你先走吧,剩下的我再看看!而从 lync 的记录上可以看出,他经常是第二天凌晨才放下手头的工作,这让我真的非常感动!同时他又是一个很勤奋的人,尤其在最后数据处理阶段,正是他的精益求精才得以让我们的数据以最完美的方式展现出来!

说来也巧,这次合作的最开始是邹欣老师让我们两个人给大家做演示,怎样通过“制作三明治”的方式来指出对方的缺点和不足,今天,当我们的这次合作即将结束的时候,我又要为李明磊“制作三明治”了!和那天的手足无措一样的是,我还是很难找到他有什么大的缺点,我想,李明磊是个勤劳而刻苦的人,但是在这次合作中,最制约我们发挥的是基础知识不够雄厚,很多计算机, c# ,甚至是 excel 的应用不够熟练,所以对别人小菜一碟儿的事,我们才会那么费周折,这是非计算机系的我们共同面临的弱点,但是这次李明磊的表现,也让我看到了他优秀的学习能力和不凡的拼搏精神,相信在微软一年的历练,一定让他更加出色!

( 10 )我的一点感想

这两周日子过得很快,但我感觉从未有过的充实,我有一个优秀的合作伙伴,有一群热心的同学,他们从未吝啬过对我们的帮助,在此,衷心地感谢那些在完成自己琐杂的工作之余还无微不至帮助过我们的老师同学!感谢邹欣老师给我们这样的机会挖掘自己的潜力,重新认识自己!特别感谢我的同伴李明磊对我的照顾!感谢见证我们努力的每一个人!

 

——谭明慧

http://www.cnblogs.com/rosting/archive/2011/08/29/2158926.html

http://www.cnblogs.com/southseven/archive/2011/08/30/2159308.html

作者: Leo_wl

    

出处: http://www.cnblogs.com/Leo_wl/

    

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

版权信息

查看更多关于现代软件工程开发体验:结对编程的详细内容...

  阅读:39次