对于这次编程项目，我只想说对不起，我失败了。只能调试通过第一个测试用例。对于后面两个测试点的高峰超载问题还没调试通过。

下面我只能写写自己的失败感受了：

1.起步较晚。

　　国庆一个假期的确浪费了许多天，基本是过完再着手写这次的项目。

2.与队友交流很少。

　　我是后来才发现结对项目附近的人都有组了，然后找了好久才发现邓亚梅没人组队才和她结对的。现在我才明白这没人和她组队的原因。可能是她个人比较腼腆，不善于表达自己的想法，而且男女宿舍不同，接触很少，和她的交流只有那么几次，也只有在qq或短信上交流多点，但她从未主动找我聊天，我实在不知道她到底有什么想法，也不知道她到底投入了多少精力进去。这次的结对项目可以说是我自己一个人的项目，这实在是有违本意。

3.在对于原代码的设计思路还没理清的时候便开始设计调度。

　　这是个非常致命的问题，对于原代码的框架和想法还没研究透彻，在许多调度判断上都产生了问题，这也是后来调试时不断产生阻碍的原因，导致了调试工作量庞大。

4.我的设计想法是：

　　每次调度时，将当前请求队列中的请求加载入最近的顺路电梯。在调度中添加了一个调度的匹配表，保存电梯和保存加载进该电梯的所有请求的链表。

　　那么，调度时每次要做的事情是：

　　　　（1）调度电梯前先判断请求队列中有没请求，有就将内部请求加载入进入的电梯，而外部请求则加载入最近的顺路电梯，若无符合条件的电梯，则将该请求返还至请求队列

　　　　（2）调度每台电梯：

　　　　　　  　若该电梯的请求链表中有请求，则电梯在自己的请求链表中寻找最近的一个请求楼层进行运动。

　　　　　　  　若电梯抵达该楼层，则将该请求移出自己的请求链表中，执行下一个请求，若无更多请求，则可设置电梯为空闲。

　　　　-顺路：电梯空闲着，则一切可达的外部请求均为顺路；若电梯有一个运动的方向，历史或当前，那么电梯往请求来源的方向要一致，且请求的方向也要一致。

　　　　-最近：若电梯接受的是外部请求，那么电梯与外部请求来源层间的距离为电梯需要运动的距离，若电梯接受的是内部请求，那么电梯与请求的目的层间距离是电梯需要运动　　　　　　　  的距离，最近的请求即是电梯需要运动距离最短的请求。

 　　正因为电梯的调度是根据链表中的请求，该设计无法判断链表中请求是否已经超载，这样是导致后面超载了还能往电梯里加入请求，但是抵达楼层后人却无法进入电梯。

5.思维被调度给固定了。

　　在之后我看了其他同学设计的代码，发现有不少是在电梯上做文章，修改后能更容易获取自己想要信息，更加方便进行调度，这也是我没注意到的地方，一直过于关注调度的设计，导致许多时候想要一些信息，但传入调度的数据不足以获取，增加了设计难度。

 6.关于结对编程的看法：

　　优点：

　　结对编程中的互相交流可以减少编程的错误，在编程的时候，大家一起检查错误，一起分析有没有更加合理的编写方法。

　　可以交流想法，可以一起探讨更加好的算法，提高算法的质量。

　　队员可以交替编写程序，将任务分散，更高效的利用时间。

　　缺点：

　　需要一定的磨合期，需要熟悉对方的编写习惯，有许多编写的格式，命名等等问题。

　　修改时，要写好注释，让对方知道自己程序的含义。

　　需要相互交流，若交流较少，会阻碍程序的设计进度。

7.程序的好设计方法：

　　信息的隐藏，或者说是程序的封装性，对于面向对象的程序设计而言，信息隐藏是一种重要的软件开发手段，它与对象的封装（encapsulation）与模块化（modularity）密切相关。这是为了保证程序的安全性，保证程序的内部信息不会被随便的获得和改写，这使得程序变得更加具有独立性，高内聚，面向对象的特征更加明显，为了保证这一点，在程序中对一些需要被外部访问的属性设定了专门的方法，通过方法的方式将内部属性传递出去。

-----Not Finish-----

结对项目电梯吐血总结