结对编程作业总结

这一次的结对编程作业我是王莹同学一起合作完成的，我们在这之外也有过合作，所以还算合作愉快，先上一张我们的合照吧。

我的战友王莹同学工作认真负责，善于思考解决问题，乐于团队合作，积极主动进行工作，缺点的话就是有时不够细致。总的来说还是一个很靠谱的伙伴的。

通过这次的结对编程经历，我们了解到了结对编程的一些优缺点。比如说结对编程时我们都更加不易于走神做别的事情，极大的提高了效率；此外，我们可以指出对方的错误，

减少比不要的低级错误；还有就是可以随时讨论，思路更加开阔；还有就是感觉上会减轻每一个人的工作压力，这样大家才敢去做能去做。总而言之，我们的合作过程还是很愉快的。至于结对编程这种方法的缺点大概可能会出现在当两个人的意见分歧比比较大的时候吧，各自都有自己的想法导致合作不稳；或者当合作对象之间的技术水平相差太过大的时候，这样的话两人可能就无法很好的进行沟通，甚至导致工作变成一个人干，另一个人完全不管的状态。

关于项目的算法，我们是在BUS算法上进行改进的。在给定的BUS版算法中，无论该楼层是否有请求电梯到每一个楼层都会停下。这样便浪费了大量的时间。同时关于四部电梯之间的相互调度，只是根据电梯之间顺序逐个进行调用，这样没有一个优化的调度方案，也会导致很多时间浪费在这里面。

通过对原有BUS版本的分析，我们得出以下几点可以优化的地方：（1）关于电梯楼层的停靠问题，当下一个楼层没有任何请求的时候，则电梯在下一个楼层不会停靠。（2）当电梯没有请求的时候，将电梯前往某一个固定的楼层，而不是让一层一层的上升/下降。（3）四部电梯之间的相互协调，通过对于电梯状态的判断，我们可以选择调用一个最优的电梯，而不是按着ID的顺序逐个的进行判断。

首先，我们对于电梯的初始楼层进行了设置，给定的电梯时1#和3#停靠在0层，而2#和4#停靠在20层，这样在面临上班或下班的高峰的时候，会倒是效率比较低，通过比较，我们将1#，2#，3#电梯停靠在1层，而将4#电梯停靠在20层。另外就是对于电梯在下一次是否停靠的判断。以电梯正在向上来讲：通过添加判断条件：if ((req.Type == RequestType.DirectionReq && req.DirectionReqSource == status.CurrentFloor - 1&&(req.UpDown==Direction.Down)) || (((req.Type == RequestType.DestinationReq && req.DestinationReqDest == status.CurrentFloor - 1) && (req.ElevatorReqIn).ID == elev.ID)))我们来判断上一层是否有请求，如果没有请求的话，则电梯在上一层不会停靠。

下面贴出两张改进后的算法的运行截图：