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

 距现代软件工程开课已经3周，按照课程安排，在最近的9天中，我们进行了极限编程模式的体验： pairwork（结对编程，具体见链接），对象是在 academic search map上添加一些新特性。经过选择，最后partner与我选了在地图上加上conference信息。
        按照标准的软件开发流程，在开始编码之前要做任务分析WBS（Work Breakdown Structure），就是把整体的工作细化到每一个细节，并且估计每个细节的工作量。下面是我们的WBS分析和实际结果的对比：

除去在开始工程之前，我们利用一天各自熟悉原有代码，结对编程的具体工作如下：

1、 将会议显示在地图上

        所有的数据都在数据库中，而且需要用c#调用Sql server获取一些统计数据，而本身对数据库的组织形式并不熟悉，用去了不少的时间。另外在编写WCF服务过程中，出现了不能正常读取数据的问题，到处排错，最后才在网络上搜索才发现是WCF的默认配置是不支持跨域。

效果如下：

可以用年份筛选会议：

tooltip事件处理：

2、 界面设计及事件

      尽管使用silverlight做界面并不复杂，但是设计本身并没有一个标准，要获取一个相对满意的效果，还是需要许多时间。

效果展示：

4、 会议搜索

      由于我的partner唐傲有这方面的经验，极大地推进了整个工程的进度。

效果展示：

5、 Bug修护及任务上传

         一者，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）预计时间花费和实际时间花费

具体说明如下：

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