一．结对编程人员:
张艺(学号后三位：185） 杨伊（学号后三位：151）
二．这是我们工作的样子：（图片）
三．结对编程优缺点：
优点：
1.结对编程时间紧密，在一定程度上可以督促双方学习，提高效率。
2.Coder在coding过程中会遇到一些细小的问题，而reviewer可以及时指出错误，并给予解决方案进行讨论。
3.遇到问题时，两个人一起讨论，并补充对方没有想到的地方，是完善程序最好的方式。
缺点：
在编程过程中，很长时间是coder在coding的过程中想思路，大概这也是每个程序员的特点，而这个时候reviewer就会长时间遇到空档期。
四．组员各自的优缺点：
1.张艺：编程能力强，思路清晰，实践能力强。但是特别容易被动漫带跑。
2.杨伊：学习态度不错，有耐心，较专心。动手能力弱。
五．说明怎样利用好的设计方法：
1.Information Hiding:信息隐藏是结构化设计与面向对象设计的基础。在结构化中函数的概念和面向对象的封装思想都来源于信息隐藏。软件业对这个原则的认同也是最近十年的事情。
以下列举了一些信息隐藏原则的应用。
(1) 多层设计中的层与层之间加入接口层；
(2) 所有类与类之间都通过接口类访问；
(3) 类的所有数据成员都是private，所有访问都是通过访问函数实现的；
信息隐藏机制在本次编程作业中是十分有必要的，乘客乘坐电梯只需知道电梯外按钮代表的含义即可，而电梯的运行机制是没有必要让乘客知道的。而程序中体现这一点的是使用private关键字实现类的封装。
2.Interface Design:接
口的有七个特性，分别是：稳定性，易用性，规范性，可移植性，鲁棒性，安全性和兼容性.而稳定性和易用性是设计接口时最基本的特性，接口必须相对稳定，否
则将导致接口的使用者和提供者为了适应新接口而不断修改接口的实现，可能重复进行无用功，严重时影响整个软件开发进度。
3.Loose Coupling:耦合性是指组件（函数）之间相互依赖的程度，而松耦合是指功能函数之间，尽量依赖程度不要太高。否则，修改完一个底层函数后，会对多个上层函数，进行大量的测试。
六．Design by Contract:契约式设计要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”，或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。契约式设计的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。
七．Unit Test:
以下是我们针对Scheduler类编写的单元测试（部分截图），从截图的右边可以看到所有方法均通过了测试:
以下是单元测试的代码覆盖率：
可见单元测试对整个程序的覆盖率是较低的，但由于我们是针对Scheduler类做的测试，因此我们点开Scheduler.dll，看看单元测试对该类的覆盖情况：
可见覆盖率达到了80%以上。
八．UML图:（VS生成）
九．算法关键以及独到之处:（源代码）
该算法的实现有一个前提，即乘客较为机智，在进入电梯时不会进入无法到达自己目标的电梯。
实现算法前需要为每一个电梯设置一个任务列表，为调度器设置一个总任务列表。API中将请求分为DirectionReq和DestinationReq两种，下文分别以方向请求和目的地请求简称。
算法实现如下：
调度器：
1.为符合条件（请求时间与当前时间一致）的方向请求生成请求，并将其加入调度器的任务列表。
2.每个tick调度器进行调度，分为以下两步完成：
（1）.为方向请求安排电梯。选择可达请求源楼层且距离源楼层最近且方向顺路或停机且没有被乘客拒绝过的电梯，将该请求入该电梯的任务列表。在调度器的任务列表中将该请求标记为已分配。
（2）.根据电梯的运行方向对每个电梯的任务列表进行排序，若上行则从小到大，下行则从大到小。删除目标层为本层的请求。检查电梯的任务表，如为空说明电梯目前已无任务，设置电梯为停机状态。否则，设置电梯的历史方向，并将任务表中第一个任务的目标楼层作为下一次电梯停靠位置。
乘客的选择策略：
1.乘客因两种可能原因导致无法进入电梯：
（1）.超重或超过人数。若如此，通知调度器重新激活任务列表中的该任务，使其可被重新安排。
（2）.电梯无法到达乘客指定楼层。若如此，将该电梯加入乘客的拒绝列表重新激活任务列表中的该任务，使其可被重新安排。
2.乘客若进入电梯，则该电梯一定可将乘客送达；将调度器中的该请求删除之。
3.乘客离开电梯与原API相同，不做改变。
算法独到之处在于考虑到了顺路策略，以及在安排电梯时尽量调度离乘客近的电梯。如果该电梯不能将乘客运载到乘客想要到的目的地，则对于该请求，这个电梯是被拒绝的，以后也不会为该乘客安排这个电梯。
然后再调度其他的电梯，这也是和现实生活接近的。
在算法优化阶段，我们考虑增加乘客的智慧，使其能根据当前来的电梯更改自己的目的地，将临时目的地设置为电梯所能运载到的最远楼层。然后再转乘其他电梯，这样可以提高电梯的利用率。
遗憾的是，由于时间紧迫，这个优化算法并没有通过所有的测试样例。
十．感想:这是我的第一次结对编程，总体感觉是很坑爹且痛苦。虽然是结对编程，但是代码基本是我一个人写的=0=感觉上我还是不太适应结对编程这种模式，我们前期阅读代码时是分开进行的，我总感觉我和一个人一起阅读代码时会看不下去（然而尽管是一个人阅读的，我的阅读过程还是很痛苦）。当我们结束了代码阅读开始进行讨论时，我发现队友对于代码的熟悉度还不够，但是时间不能耽误，于是我们进入了算法设计环节。原本是想由队友设计一个大体的算法，我进行补充并进行编码，但是队友很难把算法从自然语言抽象到程序步骤。于是我设计了一个基础的算法并进行编码，在这个过程中我们尝试进行二人工作交换，但是很快我发现了一个数据结构使用上的错误，指导队友又太慢了，所有只好换我上阵。当算法实现完成后，进入调试阶段，队友更是没办法插进手了（因为她虽然理解大体的算法思路但是不能完全理解思路在代码里的实现）。虽然我也尝试安排调试和一些小工作给队友，但是结果都是在队友完成前我就等不及先完成了。
结论：结对编程两个人的编程水平不能相差过大。对于编程能力较弱的同学，另一个人可能会给她造成压迫感，导致自己羞于编程。另一方面会产生对队友的依赖，导致对自己的不自信。而对于编程能力较强的同学，忍耐队友跟不上自己思路的过程也很痛苦，而又由于时间有限，不能浪费时间让另一同学慢慢熟悉，最终也只能本着“能者多劳”的原则变成个人主义。虽然最终一个人也能完成两个人的工作，但是非但过程痛苦，并且无论代码还是算法的质量都比不上两人合作的结果。
最后需要说的是，并非两人水平相差较大就不能结对编程。只是这需要较弱的那个人足够勤奋，更早的开展、熟悉工作，并且项目的时间要求也不紧迫，较强的人可以慢慢指导帮助较弱的人。在这种模式下，才能同时实现对两人的提高。