pairProject

额···请允许我先说一些与我的算法无关的东西

这次老师给了一个frame，只让我们设计一个电梯的scheduler类就好

但是问题在于，老师给这个框架的时候，没有说明这个框架里到底有什么。举个例子，这次的Scheduler里，只有一个Run方法。而我在含有Main的World类里却找不到调用它的语句。搞了很久，才发现这个Run基本是每个tick就要运行一次的。

如果不搞清楚run是多少时间跑一次，那么这个算法就很难写，而且不知道怎么去写了。还是烦请以后老师给出框架的时候，告诉我们这个框架里完成了什么，这个框架中，什么东西已经是给出的，程序的大概流程。或者至少给一个文档之类的东西吧···

要不，完成这个PairProject需要花费很多时间去搞懂这个代码内部到底是如何运行的。

OK，言归正传。

我这个电梯的算法就是模拟了日常生活中电梯的运行机制。

如果电梯处于空闲状态，那么电梯会响应距离它最近的一个请求。然后根据乘客的需求将乘客送到相应的地方

如果在电梯的运行状态中，接受和HistoryDirection方向相同的请求。对于和HistoryDirection方向不同的请求不给与响应

对于电梯内部，设置一个List存储乘客的目的地，根据电梯运行方向取最近的目的地，发出reqStopAt的请求

 

下面我来说说结队编程的过程和感触

我们约定了一个时间，说在一起编程。不过，第一次约好时间之后发现这个frame完全不知道它提供了什么，要我完成什么东西

所以不得不重新约定了一个时间，并约定在下次见面之前完成对frame的理解和读

当第二次约定在一起的时候，又出现了一个问题，每个人对frame的理解程度不一样

所以在这次结队编程的编码的过程中，2个人非常不协调，因为对frame的理解不同，只能由理解程度较好的人去编程，另外一个人在旁边协助。

不过在最后的Debug的过程中，2个人的效率是比1个人要好很多的，因为在Debug的时候，2个人的看法比1个人更全面，同时，2个人能提出全面的产生bug的原因。在解决BUG的时候，2个人的解决方案也更多，更好。

 

因此，结队编程的优点是：

1.能够很大程度的拓宽编程思路，提高编程效率

2.旁边有人的时候， 写代码更加专注，同时不容易走神

缺点：

在2个人对项目的了解程度不同的时候，协调困难，只能停留在很表层的合作

 

我的pair的优缺点

优点：

1.有耐心，在我都不想调试代码的时候，依旧能够努力调试

2.解决问题思路广

3.对这结队编程的事上心，在我都快忘了这个事的时候能提醒我····

缺点：

准备工作做的不好，frame没读完（虽然我也没读完···但是我大概搞懂了意思）

 

最后附合影