11061146&&11061164
前言：
拿到项目以及分组时，我与我的搭档进行了了解分析，并交流了一下我们各自的特点，进行了分工，因为我算法、编程能力比较强，所以我主要负责代码的算法设计，我的搭档c#用的比较熟，所以她主要负责阅读和理解代码，我们每天都抽出一段时间一起讨论和修改代码，结队编程也是极好的~
上图为我们在自习室修改代码的图片。
博客主要分为七个部分：
◆Part 1 关于结对编程
◆Part 2 Information Hiding, interface design, loose coupling
◆ Part 3 关于契约式编程
◆Part 4 unit test
◆Part 5 UML图
◆Part 6 算法核心
◆Part 7 总结
Part 1 关于结对编程
1.1、结对编程优点
1) 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。
2) 程序员互相帮助，互相教对方，可以得到能力上的互补。
3) 增强代码和产品质量，并有效的减少BUG，而且代码也写得更为优雅和紧凑。
4) 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
5) 降低学习成本。一对程序员工作的时候，水平较低的一方会潜移默化地受水平略高的程序员影响，学到一些新的东西。而水平高的一方同样因为不断地把自己的想法说出来。
6) 整个的设计思想由后面只动口不动手的人主导，而由操键盘的人做实现。由于人的思维速度是快于输入代码的速度的。那么观看的人可以有空闲的时间做额外的思考，可以更快更有效地解决问题。
7) 在心理上, 当有另一个人在你身边和你紧密配合, 做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄。
8) 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。因为一个人的知识已经被其他人共享。
9) 结对编程避免了“我的代码”还是“他的代码”的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。
1.2、结对编程缺点
1) 对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。 有时候，程序员们会对一个问题各执己见（代码风格可能会是引发技术人员口水战的地方），争吵不休，反而产生重大内耗。
2) 对于队友的不信任也有可能产生比一个人思考更大的内耗。
3) 两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
4) 结对编程可能让程序员们相互学习得更快。但有些时候，学习的不一定是优点。比如，合伙应付工作，敷衍项目。
5) 面对新手，有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐。
6) 新手在面对有经验的老手时会显得非常的紧张和不安，甚至出现害怕焦虑的的精神状态，从而总是出现低级错误，而老手站在他们后面不停地指责他们导致他们更加紧张，出现恶性循环。
7) 有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。
1.3、队友互评
通过这一次结对编程，我们都对彼此更加的了解。
以下是我们对对方的评价：
黄剑锟评价孙时：优点：细致，善于沟通，思维活跃
缺点：编程能力较差
孙时评价黄剑锟：优点：专注，编程能力强，对于代码的理解力好
缺点：比较习惯独立解决问题
Part 2 Information Hiding, interface design, loose coupling
2.1、Information Hiding信息隐藏
信息隐藏也可以直接理解成为封装。在面向对象编程里，信息隐藏通过让代码从一个不确定的状态变为使用一个定义良好的接口，降低了软件开发风险。客户端的接口纯粹是用于执行，如果代码的实施发生变化，客户端不必改变，这样也降低了复工率。同时信息隐藏提供了灵活性。这种灵活性允许程序员修改计算机程序，以更好地满足用户的需求。这一点在以前的一些小程序中很难体会到。不过在这次的项目中，很多类及方法的定义都是封装起来的，架构直接提供一些可用的接口。在我们修改代码的时候，应用起来十分方便，不用考虑太多。
2.2、interface design接口设计
接口是提供给其他模块或者系统使用的一种约定或者规范。因此接口必须要保证足够的稳定性和易用性。首先，接口的语义必须明确。包括接口调用方法、接口名称、参数的类型和名称。抽象的接口名称或者参数名称使人困惑或者理解错误。这一点深有体会啊，虽然所给的代码几乎没有注释加大了代码的可读性，不过至少每一个接口的名称都用英文或英文缩写指出其作用，有利于其他程序员在已有的基础上进行修改使用。其次，接口的参数不宜过多过于复杂，过多或过于复杂的参数不利于接口的调用。再有就是接口的设计一定还要考虑到安全性的问题，也就是说接口定义时需要严格限制参数的读写权限，这一点在所给的代码框架中有很强的体现，同时也为我们以后定义接口时起了一个很好的表率作用。
2.3、loose coupling松散耦合
在实际的工程中，松散耦合是指模块之间要尽量保持独立，模块之间尽量少的牵连，以免修改一个模块后导致其他模块的异常。这样便于程序的修改和管理。
Part 3 关于契约式编程
契约式设计或者Design by Contract (DbC)是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。有以下几个特点：
- 契约关系的双方是平等的，对整个bussiness的顺利进行负有共同责任，没有哪一方可以只享有权利而不承担义务。
- 契约关系经常是相互的，权利和义务之间往往是互相捆绑在一起的；
- 执行契约的义务在我，而核查契约的权力在对方；
- 我的义务保障的是你的利益，而你的义务保障的是我的利益；
在面向对象编程中，若一个类的函数提供了某种功能，那么它要：
- 期望所有调用它的客户模块都保证一定的进入条件：这就是函数的先验条件—客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况。
- 保证退出时给出特定的属性：这就是函数的后验条件—供应商的义务，显然也是客户的权利。
- 在进入时假定，并在退出时保持一些特定的属性：不变式。
契约式编程使得多人合作的团队项目更好管理和协作，并降低了后期维护的成本。
Part 4 unit test
Part 5 UML 图
Part 6 算法核心
整体思路和现实中的电梯差不多。
分为两个部分：◆乘客上电梯 ◆乘客下电梯
◆乘客上电梯：
电梯分为两个状态：停止状态和运动状态。
（1）电梯在运动状态的时候：
每到一个楼层进行一次判定，若无请求则电梯继续运行。
若有请求，则判断请求的方向与电梯当前运行方向是否一致，若一致，则电梯在该层停，让乘客上电梯。
（2）电梯在停止状态的时候：
说明此时电梯内部已经没有乘客了。若此时依然没有请求时，电梯回到初始状态。
若此时有请求，则分情况讨论：
1.若是上班高峰（之前有一个函数进行判断）：则优先响应“在电梯下面的人要下去的”然后再响应“在电梯下面的人要上去的”，最后响应另外两种情况。
2.若是下班高峰（之前有一个函数进行判断）：则优先响应“在电梯上面的人要上去的”然后再响应“在电梯上面的人要下去的”，最后响应另外两种情况。
若不是以上情况，则分电梯此时处于的楼层进行讨论：
3.若此时电梯处在13层以上：则优先响应“在电梯上面的人要上去的”然后再响应“在电梯上面的人要下去的”，最后响应另外两种情况。
4.若此时电梯处在6至13层： 则优先响应“在电梯上面的人要下去的”然后再响应“在电梯下面的人要上去的”，最后响应另外两种情况。
5.若此时电梯处在6层以下： 则优先响应“在电梯下面的人要下去的”然后再响应“在电梯下面的人要上去的”，最后响应另外两种情况。
通过这样分情况讨论能够很大的减少平均所需时间。
◆乘客下电梯：
这一部分比较好处理，只需要在每一层都进行判定，看是否有乘客的目标楼层是该楼层，若有，则将符合条件的乘客都下电梯，若无，则电梯继续运行。
Part 7 总结
通过这一次结队编程，我们都学到了很多，第一次结队编程虽然一开始进行的并不顺利，但之后渐入佳境，也慢慢体会到了结队编程的好处。在一个项目中的分工与合作，互相之前的协调，将是我们今后主要的工作方式，所以现在多经历一些结对编程、团队项目对我们今天是有很大帮助的。希望之后能够多在这一方面得到锻炼。