软件工程pair work之感想 by 张婷

历时两个星期的pair work总算告一段落，在最后presentation结束之际，回顾之前经历的种种困难以及克服后的喜悦，想跟大家分享我们的成果与收获。

Pair work的项目是对academic map进行一些补充和修改，项目的分配原则是大家玩一个number game，按赢者的先后顺序选题目。我很庆幸自己猜中了，首先选了一个觉得很有意义的项目，就是对机构下的author进行多种排序。源代码对作者是按其论文的citation count来排序的，然后把作者呈螺旋形展示。我们的目的是不仅按citation count ，还要按publication count来排序，并且能给用户一个选择的空间，能够自由选择按哪一种排序。这是原来的界面。

首先，我们对这个问题进行了讨论和分析，然后得到它的WBS：

1． Sort: 要对publication 排序

2． UI：设计界面使用户能方便地选择排序

接下来，我们开始钻研源代码，了解大致框架，并对我们问题的相关部分代码进行了深入探讨。在源代码中找到了这样一句话String u=string.Format(…&EndIdx={3}&OrderBy=CitationCount…)。原来源代码是用academic search API直接得到前50 个 citation count 最高的作者，那么我们能不能也用API 得到前50个publication count的作者呢？于是，我们查看了API使用手册，发现上面提供的排序只有三种：Citationcount ，Year ，Rank。并没有提供publication的排序，这就意味着我们得自己进行排序，难道要把所有的作者都从API上获得然后进行排序吗？算法时间和数据大小都是个限制，这时，我们做了个假 设，即大部分情况下，如果一个作者其论文的citation较高，那么他的publication也相应较高。所以，最终的解决办法是得到前100个citation高的作者，再按publication排序得到前50个，我们认为这是比较合理的。

然后，UI的界面设计也历经曲折，先放一个我们最初的一个雏形。

红框里圈着的就是我们的界面按钮，第一次做出来时挺高兴的，结果大家反映实在太难看，其实现在自己看着也觉得实在是不美观。于是，我们就想办法去改进，既要美观，又要方便，还要触发事件能够较好调用，经过我们科代表唐傲的建议，下图便是最终的界面。右面的红框里是我们的菜单，并且可以随着展开作者自动弹出。

最后，花的时间远比我们预计的要长，这是为什么 呢？可能是我们对问题的认识不足，以为排序就是很简单的把citationcount改成publicationcount，以为界面就是在原来的基础上增加两个按钮并添加触发事件。可是，真正做起来时，更多的问题才浮现出来，这时也更能体现合作的力量，互相鼓励，互相督促。下表是我们对各项工作的预计时间以及真正花费时间。

合作关系是一个磨合的过程，也许有人会觉得自己一个人说不定更高效，有时的确是这样。比如，我俩最开始是一起看代码，发现进度实在太慢了，然后决定分开看。但是，合作的优点在于你不光一个头脑在想事情，俩人或多人在一起更能产生好的想法，所谓三个臭皮匠，顶个诸葛亮嘛。所以虽然我们是分开看代码，但最终是一起讨论，分享心得。其实最重要的一点是我从对方身上学到很多东西，我的同伴钱一鸣是一个非常优秀的人，程序写得和思维一样快，通过这两周的结队编程，增进了友谊也提高了自身。

pair: 张婷 & 钱一鸣

转载于:https://www.cnblogs.com/OMG-Team/archive/2011/08/29/2158185.html