结对项目：电梯调度算法的实现和测试——报告

一、编程人员

　　徐方宇、陈少杰

二、工作照片

三、结对编程优缺点

　　优点：

　　1. 程序员互相帮助，互相教对方，可以得到能力上的互补。

　　2. 可以让编程环境有效地贯彻Design。

　　3. 增强代码和产品质量，并有效的减少BUG。

　　4. 降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。

　　5. 在编程中，相互讨论，可能更快更有效地解决问题。

缺点：

1. 对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
2. 两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
3. 面对新手，有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐。

四、组员各自的优缺点

1. 徐方宇：编程能力、阅读和分析代码能力强，有耐心，为人友善。有时注意力会被游戏吸引过去。
2. 陈少杰：与队友相处和睦，细心，编程能力较好。代码的分析能力较弱。

五、利用这些好的设计方法

　　1.Jnformation Hiding

　　信息隐藏是结构化设计和面向对象设计的一种很好的方法。的可以让我们在调用一些方法的时候，不必关心这个方法的内部是怎么实现的，只需要了解怎样使用即可。这样可以减少代码量，并降低编程难度。

　　在这个电梯的调度程序中，我们可以把一个功能用一个方法实现，在需要该功能的地方调用该方法既可。比如在passenger类中定义EnterElevator、LeaveElevator方法来实现一个乘客进入电梯、离开电梯的过程，在需要完成这一过程的时候，只需要调用这一方法即可，不必考虑这个方法的实现方式。

　　2.Interface Design:

　　接口实际应符合六大原则：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则。

在电梯调度程序中，我们把IElevator、IPassenger等设计为接口，在实现该接口之后，传递数据可以以接口中的数据来进行，方便方法的实现。

　　3. Loose Coupling：

　　松耦合的目标是最小化依赖，即功能函数之间，依赖程度尽量不要太高，能让编程者不至于对一个函数修改之后，使得其他函数跟着它一起修改很多。

六、Design by Contract、Code Contract

　　契约式设计要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。它把类和它的客户程序之间的关系看作正式的协议，描述双方的权利和义务。

　　优点：契约式设计可以获得更优秀的设计，提高程序可靠性，帮助调试，并能支持复用。代码契约则可以通过契约来设计，能显著地减少软件中的潜在缺陷。

　　缺点：个人感觉，契约式设计不利于编程过程中融入编程者的新想法——在契约确定之后，就要严格的按要求进行设计，即便有更好的设计，也不能随意对原设计进行修改。

七、UML图

　　

八、算法

　　在这次程序的编写中,我们把电梯只知道梯内人数,梯内重量当做前提条件,这样和现实情况比较符合.

　　在考虑电梯调度算法时,我们发现这样一个问题:当很多人都在某电梯内时,电梯再进入一个人就要花费梯内每个人一段等待开关电梯门的时间,造成较多的时间的消耗,所以当调度电梯时,我们优先考虑人少的,重量,人数有余地的, 运行方向和叫梯方向相同且能顺的上路的电梯去完成叫梯请求.

　　在这种请求的分配方式之下,电梯在当前运动方向上运行,只在有梯内外请求的楼层停靠,完成当前运行方向所有的请求后,就掉转方向继续完成另一个方向的请求.

九、结果分析

　　电梯调度程序的编写并不算顺利,在编写完程序后,passenger1的测试顺利地通过了,可是passenger2中存在死循环.经过调试后,虽然跳出了passenger2的死循环,但是调度效率很低, 之后又陷入了Passenger3测试的死循环,调试了很久终于又跳出来了.

　　经过分析,我们认为导致程序运行效果不好的原因如下:

1. 调度算法不够细致.可能太过注重电梯人数少这个条件,导致电梯运行时可能会牺牲较近的电梯选择而去选择十分远的电梯,而且一直将指令分配给人数最少的可执行电梯也可能造成指令分配的混乱,增加不必要的路程.
2. 思路与电梯程序的基本框架有所矛盾.在编写程序的过程中,为了能满足调度算法的逻辑,我们挪动了部分代码所在的文件,而且覆盖了一部分代码原本的逻辑,这些做法无疑都十分危险,会增加很多意想不到的麻烦.
3. C#知识的欠缺,读代码能力不足.说来惭愧,这又是我们第一次用C#来编程序,我们对C#这门语言的理解很薄弱,这次作业需要阅读的代码量也不算少,虽然我们花费了近两天的时间去读代码,可是还是不能做到理解透彻,否则思路也不会和程序的基本框架出现矛盾.
4. 代码不工整,编写习惯不好. 编写的过程中,有时都会分不清括号的对应情况,而且每行代码的退格也不整齐,增加理解上的困难;有时会临时想到在某个地方再添加逻辑判断之类的语句,于是只能临时在作用的代码段的前后添加,格式又变得更混乱;编写多层嵌套的习惯也让算法的实现变得麻烦又易错.

十、感想

　　这次调度算法的编写,与其说是学习编程，不如说是一个反省的过程.在编写的过程中，真的发现了自身存在的很多问题，这些问题之前其实一直都在，只是没有引发真正的麻烦。当我们面对更深入的学习任务时，它们就会限制我们的能力，降低效率。通过这次作业能发现这么多自身的问题,我们感到十分庆幸。