结对编程——电梯调度

 

 

结对编程

彭笑东10061148

刘牛顿10061167

经过一个周末的工作，同伴和我终于完成了代码部分并测试优化，现在简单写下博客。

结对编程确实比较新鲜，跟个人作业和团队项目都不同。

个人作业对独立性要求高，整个代码的工作从头到尾从想算法到具体实现到编译通过到效率优化，可以说工作内容很全面。团队项目刚好相反，组员分工明显，每人负责其中一部分，工作内容细化。

与这两个不同的结对编程，优点是分工没有那么细化，相对而言每个人几乎都是参与了整个程序的内容，只是在小的方面有所分化，这样有利于对代码全面的理解和对算法清晰的认识，最后优化起来或者发现BUG找问题时两个人都能想到一些办法，比较好解决。

另外结对编程时两人相互讨论，互动性高，发现问题时可以停下来一块儿先解决后再继续工作，不像团队项目时发现问题不能得到及时的第一时间的讨论和解决。

要说缺点，个人觉得结对编程其实比个人作业多了一个固定的讨论对象。因为平时写个人作业时，大家遇到不会的地方或者发现某些问题或者找不到算法的头绪或者想不到优化的方法，也就是到处找人请教到处找人讨论或者求助大神。结对编程不过是把这个对象确定化了。

说到结对的两个人，其实大家都是几年的同学，平时写作业时也经常在一块儿讨论的。这个还与分组有关，这次的结对分组应该是随机的，有的人和外班一起，有些哥们呢荣幸跟妹子一起- -。

我们俩在一班，平时都对对方的情况比较了解因此分工的时候很快或者很明确。优点嘛要说三个，这个很多，笑东工作认真；有较强的编程能力，对问题有独到的见解；代码优化时总能找到解决问题的办法。我嘛分析情况比较多，写东西多，找问题快，缺点是爱玩，不能把工作时间压缩。

关于Information Hiding, interface design, loose coupling章节里的一些设计方法：

信息隐藏，接口定义，松耦合，使程序具有良好的封装性，便于扩展功能而不影响缘由的类。在电梯调度的程序中，使用了不同的接口，并将接口封装到commons.cs 文件中。恰当使用这些接口，继承拓展原来简单的scheduler，同时在拓展原scheduler类的同时，我们也充分利用以上方法，拓展员初始化类和QueueReq类，并将各种判断条件从主题函数run()中分离出来，方便以后修改复用。

描述 Design by Contract, Code Contract中做法的优缺点:

Design by Contract（契约式设计）是Bertrand Meyer总结的一项设计技巧，也是Meyer发明的Eiffel语言的主要特点。不过，这条原则的作用范围并不局限于Eiffel，而是所有的程序设计语言。约式设计的主要目的是希望程序员能够在设计程序时明确地规定一个模块单元在调用某个操作前后应当属于何种状态，是一种设计风格，一种语法规范；而且契约有助于测试。

程序代码合约(Code Contracts)是.NET Framework 4.0的新功能。使用Code Contracts主要有这些特点:提升自动测试程度，静态验证，执行阶段验证，文件产生。

UML图：

 

 

 

 

 

 

关键算法说明：

算法的关键部分在于电梯运行时的判定优先条件，这个决定了代码的运行效率。

我们采用静态就近原则，这个算法非常简单。当电梯静止时，将历史前进方向和历史状态两个参数重置，重置为当前请求的目标楼层，并选择目标楼层中最近的一个。

当电梯运行时，若请求跟运行方向相同，则选择请求中最近的一层，沿历史方向前行至边界条件（顶层或底层）。

进行代码优化时，我们将电梯静止时的停留层从随机置为随机0或1，因为大部分人从1层或0层搭载电梯。实际测试运行时发现效率提高了10-30S。

另外我们讨论了是否将相邻层数间旅行的请求忽略，确实这样做在代码运行时能够将效率再提高一部分，但在实际情况中存在BUG，比如说某人就是要从5楼乘电梯前往6楼，总不能忽略他的请求把他从5楼带到7楼吧。因此我们摒弃了这种优化方法。

END 2012-10-22

转载于:https://www.cnblogs.com/fenglq/archive/2012/10/22/2734109.html