第二次博客做业

第五次做业

1.度量分析

 

 

因为电梯线程须要控制本身的运行，关于运行的判断过多，if嵌套过多,if用的也太多，致使Nested Block Depth和McCabe Cyclomatic Complexity标红。

2.类图

 

 

enter线程负责输入，调度线程（sche）负责调度电梯请求，根据规则分配给各个电梯，而电梯线程（lifts）负责执行本身所分配到的请求，掌管本身的运动。其他的是一些请求类，请求队列，电梯类等等直接继承上次做业的。

3.关于bug

此次做业因为粗心，没有及时将电梯运动量传至调度线程，致使公测那个点挂了。而笔者负责测试的程序并无发现bug。

第六次做业

1.度量分析

 

 

因为笔者的监控线程，用了过多的if语句嵌套，致使Nested Block Depth和McCabe Cyclomatic Complexity标红，此外笔者的监控线程负责整个监控器的运行，因此将太多功能赋予它了，整个类显得冗余复杂。

2.类图

 

 

监控线程（monitor）负责了太多功能，基本监控线程全部的运行方式都在monitor类中实现，致使整个类看起来至关冗余，且难看。

3.关于bug

因为以前觉得Modified只是最后修改时间发生改变，但笔者觉得若是最后修改时间和大小都发生了改变就不是Modified，而是size-changed，最终致使Modified树被报错，且Modified关于这部分测试也被测试者挂满了bug，实在是很惋惜。此外笔者的编码格式忘记修改，不是UTF-8也被报了个incomplete，并且非法请求会占用笔者的10个线程中的名额也被报了incomplete，总之此次做业让笔者深入认识到了细心的重要性。而笔者测试的程序此次也没有发现bug。

第七次做业

1.度量分析

 

 

笔者的taxi线程掌管其全部运行，致使这部分的代码过长，判断运行方向过多，最终致使McCabe Cyclomatic Complexity标红，此外调度线程（sche）的判断嵌套过多，致使Nested Block Depth标红。

2.类图

 

 

主要有出租车线程(taxi)以及调度线程(sche)，请求类(Request)和寻找最短路径类(即bfs类)。

3.关于bug

此次因为在乘客请求无车响应时，没有通知乘客，而被报了个bug，此外因为笔者的请求红框在GUI只会显示最后一个，这让笔者的测试者感到困惑。而笔者测试的程序此次感受水平明显降低，公测中明显（80，80）已经超出地图范围却会继续执行，最后致使程序crash。此外程序的运行也莫名其妙。

心得体会

笔者认为多线程中相当重要的即是线程安全，若是不对线程加以控制，每每会出现不少莫名其妙的错误，这是因为线程竞争的不肯定性，在第一次多线程时笔者觉得加了synchronized 便能解决这个问题，如今笔者才发现线程安全更依赖于一个好的架构，不是全部的共享资源都须要加锁，另外也须要注意死锁的问题。此外笔者发现一个好的写代码风格可以极大的减小bug的出现率，另外调试bug时因为本身程序的简洁性可以一目了然哪里出现了问题。把每一个类的功能具体化，分类化，这样出现bug也能很快知道哪里出现了问题。