电梯调度算法 软工 Pair Project

软工要求的结对编程，随机分组，然后，我和七班的郭立轩(学号后三位196)分在了同一组。之前并不认识，虽然如此，这次结对编程的经历还是相当愉快的，也学到了不少东西。

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自动生成，并去掉了不重要的部分，以便容易的看出主要操作的类之间的关系