第一次作业分析
鉴于第一次作业只有两个类，这里仅展示复杂度分析
第一次作业由于比较简单所以可以看出各项值都较低，但对比其他人的程序，我的Average有些偏高，这应该是我的方法分得不够细所致。
第一次作业中我自己和所测程序均无bug，但在写的过程中遇到了正则表达式过长导致爆栈的情况，这在当时确实给我带来了不少的困难。即使是从现在来看，这种情况也十分特殊，很难找到bug产生的位置。最后我采用将多项式分段匹配的方法来减少正则匹配时的计算量。
第二次作业分析
第二次作业就能够很好地体现面向对象的思想。然而我的很多类并没有充分运用，有些类过于冗杂。
第二次的复杂度就比较难看了。我将大部分不知道该归为哪个类里的计算过程都放在了RUN里，导致这里成了爆红的重灾区。
此外我运用了大量的复杂的判断语句，这些语句如果能进行拆分或者直接写成方法我想能够一定程度地减少复杂度。
我在这次作业中并没有充分地理解指导书中的要求，导致出现了一些本质性的错误。
而对于我的测试对象，除了测试基本的测试样例，我对其中的比较特殊的结构专门构筑了测试样例，但均未出现错误。
第三次作业分析
从复杂度和类图来看这次作业与第二次作业并没有太大差别。
第三次作业是第二次作业的进阶版，虽然增加了捎带看似并没有太大的改变，但在编写过程中却发现bug成倍的增加。可以看出虽然仅仅增加了一种要求，但这个要求会和之前的请求产生很多特殊的情况需要处理。而我的bug也是因为情况过于复杂，产生了“拆东墙补西墙”的情况。这个bug具体来说是在Queu中判断捎带时产生了逻辑上的错误。
而我这次的测试对象代码结构清晰，逻辑明了，但输出格式上存在问题，并且对于一些变量类型的运用有些问题。
总结
经过了三次作业，我最深的体悟就是首先要认真阅读指导书，搞清需求和逻辑。其次就是写代码的时候一定要从一开始就做好规划，对其中每一部分的作用和整体的逻辑结构要有明确的认识，这样才能在更改代码的时候知道这次改动所会带来的影响。