设计策略及其变化

第五次作业-多线程电梯

在这次作业一开始的大部分时间，我一直想着怎样设计最为完美，完全使用BlockingQueue，导致交作业前发现设计并不能满足指导书的要求。最后仓皇之中加了一个新的类，既臃肿，又是轮询实现，导致出现了bug。

第六次作业-IFTTT

这次作业采用了不同照snapshot的方式实现，由于对指导书理解有些问题，导致出现了一个未考虑的情况。这次作业中线程安全的文件类的设计加深了我对线程安全以及Java文件操作的理解。

第七次作业-出租车调度

这次主要使用了锁来实现线程安全，我的地图类有放置等待的请求和找最短路两个功能，寻找最短路是没有安全问题的，而放置请求需要线程安全。其他的部分都和以前类似。

基于度量的分析

第五次作业-多线程电梯

这次作业在OO度量的表现上其实还不错，也是因为前期花了不少时间去设计，但是最后却发现设计中有一个没考虑到的地方会导致不符合题意，因此最后只能匆忙改变了设计，增加了一个不断轮询然后向电梯发送请求的Work Thread，这样的做法其实还是不怎么好的。

第六次作业-IFTTT

类的设计还是不错的，采用了不断拍摄“快照”，再对比快照的方式。这里比较有意思的是文件安全类，使用了一个HashMap，以绝对路径为key，以File对象为value，获取文件只能通过静态方法getFile，从而不会出现有两个File对象指向同一个文件的情况。

在线程安全方面，还是采用了BlockingQueue解决一切问题的方法，比如监控器向负责输出文件的类传递信息都是使用BlockingQueue。这种方法简单，而且也保证了线程安全，不错！

第七次作业-出租车调度

这次作业就比较烂了，其实一开始还是花了不少时间来分析的。例如为了不开上百个线程，我让两个线程CarsController和RequestDispatcher分别负责调度所有的出租车和请求。另外一个RoadMap类负责放置请求和寻找最短路。总体设计比较合理，但是细节上出现了很多问题，例如从上图中可以看到，各个类的耦合程度相当高，而且主线程似乎没什么用但又不能去掉，有一种食之无味弃之可惜的感觉。

bug分析

第五次作业-多线程电梯

我方：

被找了一个bug，是由于之前所说，最后时刻发现设计问题然后匆忙改正，导致出现了bug。

我采用了一个特殊请求作为程序结束的标志，所有线程拿到该请求后之星完手中的活后结束。而我写的用于分配请求的轮询线程由于没有考虑清楚，可能把所有的结束请求发给一个电梯。

对方：

对方的时间模拟似乎是以1s为单位，不知道为什么会这样，但确实避免了一些bug。其他方面，他在捎带请求方面出现了一些问题，均已被发现。其实我是当做黑盒测试的。

第六次作业-IFTTT

我方：

这次作业虽然互测没有bug，但是公测出了3个错误，这是由于这次作业会出现很多边界情况，而我又懒得去管，认为没有人会闲到去测这些，没想到却被测试了。bug就是有多个文件时我不能他们变更时的一一映射关系，实际上要实现并不难，也是懒惰造成的。

对方：

对方的程序写的不错，我也没找bug，实际上对方的代码也会出现我的那个错误，但我并没有报上，其实也是因为一开始并不任务这是一个错误。

第七次作业-出租车调度

我方：

这次被找出来5个bug，虽然确实有很多失误，但是也有一些bug我认为是不合理的，因此现在也正在和对方交涉。其中一个bug是我在为出租车安排任务时的距离信息是直接计算了曼哈顿距离而非BFS得到的最短距离。还有一些bug可以说是压力测试了，我的程序确实写的很烂，被测出来也情有可原。

对方：

对方有一个比较明显的bug，就是在增加信用时在乘客刚上车时就进行了。

另外我还报了一个设计错误——对方的出租车的状态分别用int型变量表示，这显然可以由枚举变量代替。

心得体会

实际上到了第六次作业之后，我便渐渐没有耐心认真完成作业了。一方面是因为好好写作业真的需要很多时间，一不小心就把一周大部分的空闲时间搭进去了，而最后的结果可能不错，但你甚至不知道是对方懒得测你的还是你的程序真的写的好。第二点就是每次作业感觉还是有一些同质化，第一次使用正则表达式，第一次互测，第一次写多线程都还是很有乐趣的，但现在兴奋点越来越少了。

怠惰的结果就是后两次作业的结果很差，对于之后的3次作业，我还是希望自己能好好对待。在策略上，首先是要早点开始，就算花的时间一样，早点开始也能给自己一些回旋的余地。另外issue虽然重要，但还是要抓住作业的重点，而不要陷入无尽的对细节的纠结中，好好写好代码才是最重要的。