电梯调度算法 软工 Pair Project —— Ever
由个人博客迁至团队博客
软工要求的结对编程，随机分组，然后，我（郭立轩）和六班的闫生辉分在了同一组。之前并不认识，虽然如此，这次结对编程的经历还是相当愉快的，也学到了不少东西。
OK，下面进入正文
关于结对编程
如何利用结对编程解决问题
我以为，结对编程的精髓在于沟通和监督。所谓沟通，就是结对的两个人能够对所遇到的问题提出想法，并和另一个人去讨论，从而达到一个取其精华，取其糟粕的效果，程序也就会比一个人在写会更好。所谓监督，其实可以说是一种长时间的相互勉励以及警醒，可以让一些在一个人编程时容易出现的问题，比如错字、分心等，几率降低，保证代码的质量，也会让人能够保持一种高昂的精神状态。
我和我的partner在一起编程时，是可以比较明显的感觉出结对编程和两个人分别编程的差别的。最明显的就是，结对编程时，有人在旁监督，错误率要下降好多，对自己的代码的要求也更加严格。同时，通过对一些细节问题的探讨，也让程序更棒。
下面是我在这次结对编程体验中的一些总结
对于结对编程
好处是：
1，两个人商量，更容易想到好的算法
2，两个人轮换编程，可以减少编程带来的疲劳感
3，分工合作，编码者专注于编码，导航者专注于分析与设计，保证代码的高质量
缺点是：两个人观点不一时，需要时间去相互说服，而且又是还不一定能说服，这就需要各自去证明自己的观点的正确性，可能造成两人之间的冲突（当然，如果没有冲突，这一点可以算作是优点。。）。而且若两个人不熟悉，沟通相对来说比较困难。
结对编程中，对两个人的评价
呃，这个评价是自己在结对编程的过程中，亲身得出的体验，以及两个人对自己的评价综合了一下。。
我自己：
优点
1，有一定的编码能力
2，容易沟通，易于相处
3，能够提出经过自己思考的想法，并充分交流
缺点：有时过于固执，敲代码是经常敲错，不善于和
闫生辉：
优点
1，勤学好问
2，容易沟通，易于相处（呃，其实感觉在学校里，同学之间都没问题。就是不知道公司里，还是不是所有人都是容易沟通，易于相处）
3，能够独立思考（这一点是相当重要的一点，一个好的程序，必然需要经过程序员自己的独立思考）
缺点：编码能力相对欠缺（在校大学生的编码能立存在普遍问题，这不仅仅是学生个人的问题，也是教育本身的问题）
关于电梯调度算法
模仿现实的电梯调度算法，“请求”驱动
具体来说，对于请求队列，依次处理每一个请求。对于一个请求，如果是电梯外的请求（Direction Request)计算出可以响应该请求的并且能够最快到达该请求发起的楼层的那部电梯，将楼层号加入到电梯的处理队列。请求队列处理之后，遍历所有电梯，若电梯已经完成所有的请求，根据是否为上班高峰期，调度电梯至1层。
一些算法细节
判断是否为上班高峰期
if countReq / (double) courntReqFrom01 > CUT_LINE: peek() else: not_peek()
寻找最佳电梯
在为每个请求寻找最佳电梯时，需要满足如下条件
(elev.HistoryDirection == Dirction.No || req.UpDown == elev.HistoryDirection && req.UpDown == elev.CurrentStatus.CurrentDirection) && elev.FreeCapacity >= MAX_WEIGHT
才有资格成为该请求的最佳电梯的候选电梯，之后再判断哪部电梯能够最快到达请求发起楼层
一些参数的设定
在算法整体写出来之后，还需要设定一些参数，以优化电梯的调度速度。下面是两个重要的参数
CUT_LINE = 0.5; // 是够为高峰期的判断界限 MAX_WEIGHT = 120; // 这个名字起得不好。。当电梯剩余空间小于MAX_WEIGHT时，电梯不响应DirectioReq FLOOR_TO = 1; // 这个是电梯在没有请求时，自动返回的楼层。取1时，性能优于取0时大约60%。。
关于电梯调度框架
下面为UML类图，由VS2012自动生成，去掉了不重要的部分，以便容易的看出主要操作的类之间的关系
对于这个框架，其实我是相当的不爽的。。哪个家伙写的代码，连注释都没有！！！还弄了那么多的接口！不过，写完之后发现，其实这个框架写的还是有许多地方值得我去学习的。。以我现在的水平看来，它的某些地方封装的确实不错，很有OO的感觉，不过，还有一些地方就感觉那么的不舒服，那么的匪夷所思，也不知道是自己的水平不行还是怎么的。。还有就是，代码的副作用，这个应该是这类语言特色吧，没有文档和注释，就得小心这个坑了。。还有就是，没有注释没有文档的代码，shit！
