第一次作业
一、度量分析
通过Metrics图给出的度量分析可以看出,代码在compute()方法上的圈复杂度较高,主要原因是这一部分代码if_else结构过多且有嵌套,从而导致了这一结果。这一部分的代码调用了Poly类中的add()和sub()方法，进行了多项式的加减运算，并进行了最终结果的输出。对此，我认为可以做的优化是对结果输出这一部分代码进行函数封装，并减少if_else的嵌套。
其他部分的代码没有多大的问题,对于输入的解读,主要使用正则表达式判断了格式,再用Matcher类的find()方法,找出一个一个多项式,然后对于各个多项式再使用find()方法,循环寻找各项的指数和系数并存入Poly类的items[]数组,用于之后的计算。在这里我第一次体会到java内置库方法的方便之处(java虽然是一种很慢的语言,但是却用它身为高级语言的方便之处在许多计算机语言种占有一席之地)。
二、类图
第一次作业的类结构较为简单:Poly类主要用于各个多项式的存储并提供多项式间的加减方法;computerPoly类主要提供了存储各个多项式的数组和运算符数组，并提供了解读输入和输出结果的方法。在设计上有一个优点是存储了各个多项式的最大的指数，这样在之后的多项式间计算时，可以当for循环达到最大指数时便停止，可以提高程序的性能。
三、BUG“恩仇录”
第一次作业自我感觉还可以,在通过所有公测的情况下且没有让我的测试者“得逞”。在bug检查方面我主要检查了整个错误分支树并设计了一些临界测试数据，在自查通过之后我“安然”地交上了我的代码，等待测试者的到来。
测试他人代码时，我首先按照bug树编写样例检查了他程序的功能性,然后再进一步细查他的代码。在他的代码中我发现了一个关于重复指数的bug，这在我代码自查时也遇到过，就是对于重复指数且指数为0的情况，程序不会报ERROR，而是把这两项当做系数为0的项处理，最后给出输出，这也是在代码设计中需要注意的一点。
第二次作业
一、度量分析
通过Metrics图给出的度量分析可以看出,代码在mian()方法上的圈复杂度较高, 主要原因是main()方法中承载了输入的格式判断函数和输入的数据读取函数,且有很多的if_else嵌套,这仍是我代码的不足,需要进一步改进函数封装。
其他部分的代码没有太大的问题，reqCur()主要用于请求的存储，而schedule主要用于请求的同质判断。
二、类图
除了类图中的楼层类(写了但未用上)，其他类都使用上了。reqCur类为请求类，主要用于存储请求和请求相关属性的读出；queueReq为请求队列类，主要使用ArrayList来管理队列的请求；elevator为电梯类，主要用于在执行指令时更新电梯的属性(包括时间、楼层等)来用于之后的输出；Scheduler类为主函数所在类，同时提供了判断同质的schedule方法。
这样分类的缺点是代码的内聚性不高，但代码的逻辑会更加清楚易懂，可以让测试者更好地理解代码。作为工程化来说，这样的代码需要很大的改进。由于我初学面向对象，所以在类的多样性上做得还不够好，这也是我想要在日后提升的地方。
三、BUG“恩仇录”
第二次作业虽然公测全过，但由于设计时的疏漏，在考虑到电梯等待很长时间后收到请求的时间更新问题时，我先将该指令去除了同质，再更新电梯时间为该指令时间和电梯时间的最大值，这样就导致了无法去除该条指令的同质。这是一个明显的错误，眼尖的测试者也发现了，并给了我一个可以接受的“error”。还有一个比较遗憾的“error”，就是我把指导书中楼层输入允许最大位数改成4位后(我代码的正则表达式也是这样写的)，交上了新的指导书，可是忘了在OO互测网站上拉取测试程序，导致指导书未更新，测试者也抓住了这个机会，用一个5位楼层输入的样例“击败”了我。但这归根结底还是我的不谨慎，在此也想提醒大家一下交上指导书后记得再OO互测网站上拉取一下自己的程序，不要步我的“后尘”。
第二次作业对他人代码的测试中，我还是采取同样的策略，首先编写样例对其进行了bug树的检查，然后细查他的代码，他的代码中犯了我在自查中的一个错误，那就是允许楼层输入位数最多10位，但却使用paeseInt读取，在楼层数的大值输入后，他的程序就出错了。
第三次作业
一、度量分析
通过Metrics图给出的度量分析可以看出,代码在command()方法的圈复杂度过高、块嵌套过深。主要原因是command()方法内部没有if_else嵌套过多,且没有进行函数的封装,自己在日后的代码中一定会改进,尽量封装函数,保证程序的高内聚和低耦合。
其他方法没有太大的问题，具体设计只是在第二次作业的基础上加上了一个捎带处理的方法scheduleALS()。
二、类图
第三次作业的类设置只在第二次作业的基础上增加了一个ScheduleALS类，主要用于处理捎带，同时也是主方法的所在类，该类继承了Schedule父类的去同质方法schedule()和对电梯控制输出的方法command()，在之后的处理捎带的同时会使用这两个方法。
类的数量相比于第二次作业仍没有显著的增加，这样导致代码仍然没有高内聚、低耦合，但这次作业是基于第二次作业设计的，所以仍是按照第二次作业的思路在走，从而导致了类的过少。我希望在下一次的作业中可以从设计之初就抓住类多样性的目标，从而使得设计的程序能更加符合工程化的标准。
三、BUG“恩仇录”
第三次作业的公测依然是全部通过，但我在处理主请求同层输出三条捎带的情况出了bug。我首先使用下标i遍历请求队列，当找出一条便放入同层队列,并将该请求其从请求队列移出，但之后我却未将下标i自减,这就会导致for的下次循环会忽略与从请求队列移出请求相邻的同层输出。由于我自测的不完备，没有测试三条请求是捎带同层输出请求且三条指令相邻的情况，从而导致了这个错误未被发现，随后被测试者找出并贴上了bug的标签。
在我测试他人代码时，我看到了他人代码类的多样性，这也是我值得学习的地方。我拿到的代码思路十分清晰，当我编写样例测试完他的功能性后，并未发现任何bug。之后，我检查了他的输入判断和Readme，发现他对于请求的INVALID输出并未按指导书的要求省略空格，我也只能报告了bug。
感悟总结
1、在设计方面，我认为更应该像老师上课时说的那样，首先设计好整体的框架和类再来写代码，这样不但能事半功倍，而且能提高程序的正确性。
2、OO这门课还是带给我很多，让我从一个java新手慢慢学会去设计面向对象的程序，然后在面向对象的基础上一步一步去挑战更难的设计。
3、在调试自己bug的过程中我也有了更多的思考，学会了在设计程序时就努力去考虑可能存在的一切bug。
4、在测试他人代码的过程中，除了寻找他人代码的漏洞和不足，更多的是学习他人设计的长处，以此来为自身今后更好的程序设计作铺垫。
5、对于继承和接口的学习也让我对java的理解踏入了一个新的台阶，之后多线程的挑战也也在鼓励着我。
6、希望大家能够和睦相处，扣分时能够将心比心(代码本身bug和Readme错误除外)。
