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[]中，并将目标改为该楼层
胡仁君 2012/10/22
