Pair project members：刘昊岩11061156，黄明源11061186

　　两周时间，工程下午刚刚结束，现做一些总结。

　　在现有工程基础上修改schedule 包下方法，主要思想是，也就是关键所在：电梯停的时候判断往哪里走，走的过程中顺路带人，电梯里有人先满足里面人的需求（就是直到把里面人全部送达目的楼层），然后回到电梯停的状态。主要代码框架如下（列个框架应该没问题吧）：

 1         public void Run()  //scan the request and make correct decision to control elevator;2         {3             foreach (IElevator elev in _Elevators)4             {5                 if (elev.CurrentStatus.CurrentDirection == Direction.No)6                     RunNewReq(elev); //电梯没动，搜索新请求7                 else8                     PickInTheWay(elev);      //电梯正在动，顺路带人9             }
10             return;
11         }

　　判断电梯当前是否运行，如果运行，执行PickInTheWay()方法，否则执行RunNewReq()方法。前者作用是在电梯运行中，把路过楼层与电梯当前运行方向有相同需求的乘客拉上来（语言表达能力有限啊= =），后者是电梯不动时候搜索新的乘客请求，这里又分为有乘客和没有乘客情况。有乘客时候，先满足内部需求，电梯运行方向与内部需求方向相同，没有乘客时候，进行一个判断（难以表达清楚，详见代码= =）

　　单元测试如下：

　　最后运行结果不是十分理想，不过比bus要好点~~主要缺陷是没有进行上下班高峰判断，曾经加入判断后有死循环和效率更慢情况出现，目前还没有好的算法，现在正与其他Pair进行交流。

　　最后把UML类图列出如下：

　　现在说下结对编程的感受，这是第一次做结队编程，感觉十分新鲜，是一种很好的工作方式，不过我们认为有利有弊。

　　首先说缺点：

1. 不能称之为缺点，只是针对我们目前情况，觉得不是十分妥当，我们觉得结队编程针对的应该是大牛级别，或者有一定编程能力的人。我们作为初学者，现在只能感受结对编程的魅力，却无法完美发挥它的优势。
2. 两个人对彼此的代码不十分熟悉，导致审核测试等过程效率降低。
3. 有时候思路不同，难分上下又难以统一。

　　然后说优点：

1. 合理分配成员任务，能使工作更高效。
2. 有助于成员间互相帮助，互相学习，提高代码水平。
3. 成员间互相审阅代码，有助于提高代码质量，减少bug发生。也能使成员间互相督促，相比较单独作战，更能让人认真起来。
4. 结对编程避免了“我的代码”还是“他的代码”的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。

　　对于本次Pair Project，我和partner配合比较成功，

　　我对partner的评价：

刚接到分组说我和明源一组，我非常高兴。因为我和明源合作很长时间了，包括英语partner在内的多次双人或多人结队活动。明源给我的第一印象就是踏实，做事稳重踏实，让我非常放心。这次的结对工作中，我们分工明确，首先我们共同讨论工作的整体算法，然后他重点搞代码优化、我重点搞图形建模，然后互相审核，共同完成博客的编辑。自始至终的所有环节，明源都一丝不苟的完成，为我们的算法思想提出了很多建设性意见，使得我们的工作完成的非常理想。虽然我们的水平不如大牛们，但是我们的收获确实超出对自己的预期值，谢谢明源对我的支持与帮助。

至于必须写的一个缺点嘛……明源你下次写代码时多写点注释，我改的时候也方便些哈。。

　　partner对我的评价：

昊岩是一个超级认真的大学霸，做事情一丝不苟，为了研究算法，特意跑到新主教去细致调查了一下实际电梯的运行方式！然后为了画好UML图一步一步调试，很辛苦的自习到很晚！超级棒的partner！而且很能抠细节，往往能注意到别人发现不了的问题，对于程序修改帮助十分大！

至于缺点，暂时还没想到~，不过他非让写，即使工程量大也不要这么学霸，给人压力好大。

　  Design by contract :

　　契约式设计（DbC），是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。

　　DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。

　　DbC的关键：

 1 put(x: ELEMENT; key: STRING) is2 -- Insert x so that it will be retrievable through key.3 require4     count < capacity5     not key.empty6 do7     ... Some insertion algorithm ...8 ensure9     has (x)
10     item (key) = x
11     count = old count + 1
12 end