pairwork 小结

0、结对人员

　　Hu(155) Tan(189)

1、关于结对编程

　　优点：coder的大部分错误可以在第一时间被reviewer发现，这省下了很多本应当在项目测试阶段花费的时间；

　　　　   结对编程写出的每一个程序都体现了两个组员中的较高水平；

              两个人轮流交换角色开发项目，加快项目进展速度；

              两个人结对开发的过程就是两个人互相学习进步的过程。

　　缺点：有时候reviewer会整段时间处于无事可做的状态；

              增加了意见统一成本。

　　Tan的优缺点：（优）接受新事物的能力强，在很短时间内理解了项目的基本框架；（优）算法设计水平高；（优）有追求卓越的精神，最终定下的版本是在最初版本的基础上进行了N次修改得到的，最后的平均花费时间仅仅是第一个版本的1/5；（缺）编程风格还是继续延续面向程序的。

　　Hu的优缺点：（优）算法水平还算过得去；（优）思维严谨，查错能力还算过得去；（优）和Tan大神的影响下追求卓越的精神还算过得去；（缺）开发大项目的经验不足，框架看了很久没看懂。

2、ASE的设计方法

　　信息隐蔽：类的成员变量的可见性统一成private，并设计相应的属性。

　　接口设计：设计接口是尽量细化，功能追去单一，不要设计功能臃肿的接口方法。

　　松散耦合：在一个系统中使各组件在最小的可行范围内彼此依赖，尽量限制类和类之间互相连接。

　　契约式设计：在调用方法前保证初始条件的正确性。

3、单元测试

4、UML类图

5、电梯调度的算法

　　先描述一下bus的算法，无视需求，每层依次停。

　　首先，我们分析了一下这个算法，这个算法很显然可以保证将每个人送到，但效率很低。

　　bus算法效率低的原因在于停了很多不需要停的楼层。

　　按照我们平常乘坐电梯的思想，很容易想到是哪一层按了电梯，电梯就去哪层，并不停中间层的。

　　这样，我们只需要记录电梯需要去哪层，把电梯派过去就可以了。

　　考虑两个变量，电梯、楼层。可以说这是一个二维的模型。由于二维模型处理比较麻烦。退化为两个一维。

     （1）每个elev查找最适合的req

　　（2）每个req查找最适合的elev（离它最近的一个elev）

　　由于总感觉(2)有点问题，并结合编码，我们选择的方案(1)

　　对于方案(1)，何为最适合的req呢

　　如果电梯处于运行状态，则查找电梯当时位置与要去的位置时，是否有人要进电梯，如果有，顺路把那人带上

     如果电梯处于停止状态，则按如下顺序查找（在楼下往下走的，在楼下往上走的，在楼上往上走的，在楼上往下走的）

　　至于为什么是这个顺序，多次实践得到的结果

　　最后，有个小优化，即电梯空闲体重小于100，就视为超重，不停了

　　至于为什么是这个数，也是多次实践得到的结果

 

　　对于如何实现这个算法，我们存储了两个信息

　　_wait记录还没有进去电梯的req

　　elevStop[]记录该电梯将要去的楼层

　　当电梯处于停止状态时，若elevStop[]不为空，找到elevStop[]中最近的那个楼层去，若elevStop[]为空的时候，在_wait中找到最合适的楼层去

　　当电梯处于运行状态时，在_wait中寻找是否可以中途带人，可以的话将该楼层加入elevStop[]中，并将目标改为该楼层