结对小组：林豪森1180 邓亚梅 1152
对于这次编程项目，我只想说对不起，我失败了。
修改的程序我放在了一个新建的文件夹中，只能调试通过第一个测试用例。对于后面两个测试点的高峰超载问题还没调试通过。
这是第一个测试点结果：
下面我只能写写自己的失败感受：
1.起步较晚。
国庆一个假期的确浪费了许多天，基本是过完再着手写这次的项目。
2.与队友交流很少。
我是后来才发现结对项目附近的人都有组了，然后找了好久才发现邓亚梅没人组队才和她结对的。现在我才明白这没人和她组队的原因。可能是她个人比较腼腆，不善于表达自己的想法，而且男女宿舍不同，接触很少，和她的交流只有那么几次，也只有在qq或短信上交流多点，但她从未主动找我聊天，我实在不知道她到底有什么想法，也不知道她到底投入了多少精力进去。这次的结对项目可以说是我自己一个人的项目，这实在是有违本意。
3.在对于原代码的设计思路还没理清的时候便开始设计调度。
这是个非常致命的问题，对于原代码的框架和想法还没研究透彻，在许多调度判断上都产生了问题，这也是后来调试时不断产生阻碍的原因，导致了调试工作量庞大。
4.我的设计想法是：
每次调度时，将当前请求队列中的请求加载入最近的顺路电梯。在调度中添加了一个调度的匹配表，保存电梯和保存加载进该电梯的所有请求的链表。
那么，调度时每次要做的事情是：
（1）调度电梯前先判断请求队列中有没请求，有就将内部请求加载入进入的电梯，而外部请求则加载入最近的顺路电梯，若无符合条件的电梯，则将该请求返还至请求队列
（2）调度每台电梯：
若该电梯的请求链表中有请求，则电梯在自己的请求链表中寻找最近的一个请求楼层进行运动。
若电梯抵达该楼层，则将该请求移出自己的请求链表中，执行下一个请求，若无更多请求，则可设置电梯为空闲。
-顺路：电梯空闲着，则一切可达的外部请求均为顺路；若电梯有一个运动的方向，历史或当前，那么电梯往请求来源的方向要一致，且请求的方向也要一致。
-最近：若电梯接受的是外部请求，那么电梯与外部请求来源层间的距离为电梯需要运动的距离，若电梯接受的是内部请求，那么电梯与请求的目的层间距离是电梯需要运动 的距离，最近的请求即是电梯需要运动距离最短的请求。
正因为电梯的调度是根据链表中的请求，该设计无法判断链表中请求是否已经超载，这样是导致后面超载了还能往电梯里加入请求，但是抵达楼层后人却无法进入电梯。
5.思维被调度给固定了。
在之后我看了其他同学设计的代码，发现有不少是在电梯上做文章，修改后能更容易获取自己想要信息，更加方便进行调度，这也是我没注意到的地方，一直过于关注调度的设计，导致许多时候想要一些信息，但传入调度的数据不足以获取，增加了设计难度。
6.关于结对编程的看法：
优点：
结对编程中的互相交流可以减少编程的错误，在编程的时候，大家一起检查错误，一起分析有没有更加合理的编写方法。
可以交流想法，可以一起探讨更加好的算法，提高算法的质量。
队员可以交替编写程序，将任务分散，更高效的利用时间。
缺点：
需要一定的磨合期，需要熟悉对方的编写习惯，有许多编写的格式，命名等等问题。
修改时，要写好注释，让对方知道自己程序的含义。
需要相互交流，若交流较少，会阻碍程序的设计进度。
7.设计方法：
信息的隐藏：程序的封装性，在之前的面对对象课程上也学习过，对于面向对象的程序设计而言，信息隐藏是一种重要的软件开发手段，它与对象的封装与模块化密切相关。这是为了保证程序的安全性，保证程序的内部信息不会被随便的获得和改写，这使得程序变得更加具有独立性，高内聚，面向对象的特征更加明显，类与类之间的交流无法直接对对方的属性内容进行操作，只能通过类所提供的方法。
接口设计：接口的设计能方便获得父类的基本属性信息，能为继承类提供一个基本框架，通过接口完成相互独立的模块之间的信息传递，很好的保护了程序的封装性，我们也能通过接口快速访问继承该接口的类的功能。
松耦合：程序模块间的依赖性低，模块间通过信息交互来联系，设计类时不用过于担心破坏其他类的问题，修改调试时可以方便定位，简单修改某个出错模块即可，不影响其他模块。
8.契约式编程：
契约的概念很简单——它只是必须为真的表达式。如若不然，契约就被违反，那么按照定义，程序中就一定有 bug 。契约构成了程序规格说明的一部分，只不过是从文档中挪到了代码中。就像每个程序员所知道的那样，文档通常是不完整的、过时的、错误的或者是不存在的。将契约挪到代码中就使得契约变得可对程序验证了。
这是保证程序中模块方法正确性的重点，也是我没有做好的地方，许多方法的处理比较模棱两可，产生了许多问题，导致调试工作量多，影响工作进度。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
