标签：没有 png 开始 增加 注意 com 同步 感受 队列
前三次作业可以说是入门编程，随着课程的深入，这三次多线程作业使我们开始慢慢接触工程性的编程任务。
对比起1-3次作业，5-7次作业明显没有那么顺利了，之前在互测环节每次最多就一个BUG或者没有BUG，并且出现BUG时一般可以比较容易的发现BUG的类型以及造成BUG的原因，但是在这三次作业中，由于多线程的部分不确定性，很多问题难以在测试中准确发现，尤其是自己进行测试时，所以这三次作业互测环节被发现的BUG较前三次有所上升，然而乐观地说，互测中被发现的BUG越多在互测环节的收获也越大（当然这是抛开分数的说辞），接下来对这三次作业做一个总结报告。
第五次作业：
该次作业为多线程电梯作业，相比起之前的电梯作业，这一次的作业的捎带算法和同质判断并没有太大的改变，改变主要体现在三部电梯的多线程机制，由于是第一次接触多线程，故大部分时间用于解决由于线程同步控制做得不得当导致的线程安全问题，调试过程中比较明显的感受是：多线程的机制决定了BUG不能总是简单的从逻辑去分析（这也是我们常说的玄学BUG），如有时直接运行出现的BUG单步调试BUG消失，根据经验来看这种情况都是同步控制的问题；另一个比较明显的区别是调试技巧，前几次作业单步调试是一种比较搞笑的调试方法 ，然而在多线程中，输出调试往往更能呈现出运行中的问题；
作业测试情况：
公测：无BUG；
互测：未被发现BUG；根据分支树并对测试任务代码进行阅读理解，在这次测试中测试程序的漏洞较大，共计发现测试程序7个BUG（包括一个imcomplete） ;
第五次作业本人类图及复杂度测试截图：
第六次作业：
该次作业为实现一个IFTTT文件监视系统；
比起第五次作业，这一次测试环节一共被扣了12分，可以说是非常不顺利了，但是这一次作业测试环节也发生了一段小插曲：由于被测程序准确度较低，在测试中时常出现一些“诡异行为”，花了两个小时对这个程序进行了一波ｄｅｂｕｇ，这样一段经历也算是换一换互测的体验哈哈；
作业测试情况：
公测：未被发现BUg；
互测：被发现6个BUG（包括一个imcomplete），五个ERROR中，有两个是README与指导书的歧义问题，有两个是因为同步控制不得当导致的偶然性BUG，有一个是由于逻辑逻辑错误，已找到BUG具体原因；
第六次作业本人类图及复杂度测试截：
第七次作业：
该次作业为实现一个出租车打车系统（系列作业，这是其中第一次作业）；
经过上两次多线程作业的铺垫，大家对多线程有了更多的理解和经验，这一次作业中，线程数明显增多（实际上我认为这一次作业的线程控制比第六次作业简单一个量级），１００辆出租车即１００个线程，而对于请求处理，我进行了两种实现，一种是每个请求一个线程，请求调度结束该线程即结束，另一种是设置一个请求队列，对于该队列的处理为一个线程（这一种实现我并未完全实现，故上交的代码为第一种实现），但是经过测试最终还是发现每个请求一个线程存在一部分难以解决的问题，故我决定在下一次作业中重构代码改成请求队列的设计；于此同时这一次作业增加了很多设计原则需要在互测中进行评定，这也是对我们编程习惯和代码风格的要求。
作业测试情况：
公测：未被发现BUG；
互测：被发现BUG4个（一个ｉｍｃｏｍｐｌｅｔｅ）；设计原则缺陷三个（虽然个人认为其中的两个设计缺陷报告中测试者的理由比较牵强，但是设计原则评定和测试者的严格程度有着很大的关系，同时本着虚心接受BUG的心态，本人并未做出申述）；
第七次作业类图及复杂度测试截图：
感想总结：
在这三次作业尤其是第七次作业中，课程对于代码风格的要求已经变得更加严格具体，一开始觉得指导书中设计原则的评定带有很大主观性，但是实际上回顾几次多线程作业，达成这些设计原则的好处是非常明显的，如果只顾着自己编程中一时的方便而忽略了这些重要的原则，我们将可能付出更多的时间用于一些由于设计风格不当导致的低级问题，并且调试的难度也更高，所以养成这些良好的设计风格是非常重要的。
到此OO课程几乎已经过半，相比起我的收获，半个学期的努力自是没有白费，希望后半程再接再厉，佛主保佑所有同学永无BUG！
ｅｍｍｍ……还有……大家注意身体，修仙要适度！
标签：没有 png 开始 增加 注意 com 同步 感受 队列
原文地址：https://www.cnblogs.com/zgj982393649/p/8976674.html
