第一次作业
1.度量分析
第一次作业的metrics图分析出现了标红的McCabe Cyclomatic Complexity和Nested Block Depth。McCabe Cyclomatic Complexity表示圈复杂度，而Nested Block Depth表示嵌套深度。标红的McCabe Cyclomatic Complexity表明类之间的职能分配不均匀。因为是第一次写作业，从始至终都只建了一个类，导致了一个类承担了所有的职能，圈复杂度出现了超标现象。标红的Nested Block Depth则表示嵌套现象严重。由于暴力的一次次匹配，不停的用if-else语句和while/for循环语句，导致嵌套很多。
2.类图
第一次作业，因为刚刚学习JAVA，对类和对象的概念不熟悉，基本按照过程化的思维去写，所以只写了一个类。在这个类里，进行了所有的操作，导致这个类非常的冗杂。
3.关于BUG
第一次作业，要求用面对对象的思维去看待问题，思考问题，解决问题。但是由于长期的面向过程编程，导致在写本次作业的过程中，很不习惯。第一次作业是多项式的加减法，总体的设计难度不大，但是其中牵涉很多的细节问题。在公测和互测各出现了两个BUG。公测中的两个BUG分别是因为正则表达式过于冗长，导致爆栈和前导零输入太多报错。公测的这两个问题，反应了思考还不够严谨，没有想到会爆栈。互测中的两个BUG则是因为在Read里没有说明嵌套输入会报错，即使实际操作中会当作一个输入错误输出和没有定义输入为{}时，输出什么。互测中的两个问题，反应了没有仔细研究各种输入输出的分类。
而作为测试者，拿到的程序公测全过。所以想到了输入和输出的问题，分别找到了两个问题，一个是只输入{不报错，以及在输入的末尾多一个“，”不报错。综合来看，第一次作业的输入输出是一个难点，很容易少考虑情况。
第二次作业
1.度量分析
从第二次作业的metrics图可以看出，出现了与第一次作业同样的问题，圈复杂度超标和嵌套现象严重。因为所写的调度的类中，承担的职能太多以及输入和调度频繁的循环判断。
2.类图
从类图可以看出，调用关系有点复杂不明确，因为写的时候没有考虑清楚各个类的方法，在写的过程中，强行放入了一些方法，导致最后对类的考虑不明确清晰。在以后写作业的过程中，会仔细明确的划分类。
3.关于BUG
相比于第一次作业的主要是输入格式的错误，这次的问题则主要是没有考虑到数据溢出的问题，导致公测中与数据溢出相关的两个测试均出错了。而互测则没有被发现BUG。
作为测试者，在拿到的程序中，发现了一个与输入有关的问题，在正确的输入后添加字符，不会报错。
第三次作业
1.度量分析
从第三次作业的metrics图可以看出，出现了与前两次作业同样的问题，圈复杂度超标和嵌套现象严重。同样是因为所写的调度的类中，承担的职能太多以及输入和调度频繁的循环判断。并且因为第三次作业是在第二次作业的基础上加入了捎带操作，导致问题更加严重，程序更加臃肿。这三次的作业，都反应了程序封装和代码简洁的重要性。
2.类图
从类图可以看出，第三次作业类的调用关系比第二次作业更清晰明确。但是思路依然有些不清晰，对每个类的职能的考虑需要更详细。
3.关于BUG
对比傻瓜电梯，捎带问题显得难度上升了很多。因此如果对捎带问题看的不全面深入，很容易出现BUG。正是因为如此，这次公测中出现了2个BUG，互测中出现了4个BUG。公测中的两个BUG，分别是副请求时间==主请求开关门完毕时间不捎带和e.sta==DOWN的部分应该在主请求处理完后，选队列位置最前的成为主请求。而互测中则主要是e.sta==STILL和e.sta==UP问题。这次作业出现了很多问题，反映了对问题分析不够深入，导致程序设计不统一完备。
而作为测试者，此次拿到一个全过的代码，所以从一条条BUG树类样例去测试，但都没有找到这份作业的错误。
心得体会
- 到目前，写了三次作业，对面向过程编程和面向对象编程的区别的感受仍然不够深入。体会到了它们之间的差异，但还不够。
- 这三次作业写完后，都出现了很多的BUG，导致投入大量的时间去处理解决。原因是设计思路不清晰有遗漏。所以以后需要把整个程序的思路想明白想清楚，对每个类的职能做明确的划分。
- 关于时间的分配和使用上，做的不好。每次都是拖到周一开始做，导致时间很紧，不得不熬夜。所以以后应该尽早开始写作业。
- 这三次作业尤其是第三次作业，反应了对细节问题考虑的重要性。在思考过程中考虑了最普遍的情况，却遗漏了一些特殊情况。以后，在写代码的过程中，应该考虑这部分代码可能出现的各种情况，予以分析和解决。