一、度量及类图
1.第一次作业
度量
类图
2.第二次作业
度量
类图
3.第三次作业
度量
类图
二、自己程序的bug
（一）第一次作业虽然只是“简单的”多项式相加，但对于仍然小白的自己来说还是历经了千辛万苦才勉强完成。。。。虽然第一次作业公测和互测中并没有出现bug，但是在写代码的过程中的确是bug满屏飞，艰苦卓绝地debug历程也是各种心酸。第一次作业中正则表达式过于复杂，出现爆栈情况，一开始自己并没有将字符串匹配过程进行拆解，直接进行匹配，最终的正则表达式复杂冗长，也不便后期检查。好不容易学会一点点正则表达式皮毛，满心欢喜以为万事大吉，结果测试过爆栈样例后程序直接crash。在周围诸多大佬的指点下，终于赶在ddl前修改好了新的匹配方式，这个重大bug的修复也的确使自己学习到不少。其次还有数组越界：在对多项式的存储过程中，对于数组的边界情况没有考虑周全，细节的检查的确麻烦，调试工具的使用也使debug效率提高很多。
（二）第二次作业在写程序之前进行了比较多的思考和规划，主要参考了PPT上的思维导图，比起第一次的面向过程体现了更多的面向对象思想，六个类的功能划分比较合理。在判断同质请求的过程中一开始并没有思路，但之后通过对请求完成时间进行记录，并将请求发出时间与之比较，可以清晰、简单地完成对同质请求的判断。第二次作业中公测和互测也没有出现bug，但这并不代表着自己的程序完全没有问题。在自己调试的过程中，出现过crash情况，主要是对于请求降序的判断出现问题，方法的返回值没有使程序正常退出。
（三）在上课看到第三次作业时，以为只是简单地对第二次作业进行修改，结果证明还是太年轻。第三次作业花费了很多很多精力，首先对于捎带条件的判断没有理解清楚，在判断电梯“当前状态时”错误地判断为相对主请求时间的电梯状态，导致捎带判断程序混乱冗杂；再者在同质请求的判断过程中出现问题，在捎带队列没有完全确定的情况下，某些当前不为同质的请求可能在之后变为同质，同质判断思路大体正确，但在一些小细节上没有留意太多。第三次作业应该是三次以来bug最多的一次，写代码时没有保持清醒的头脑，很多问题一概而论，list为空，for循环边界等等一系列细节问题，使得debug过程困难重重。虽然公测没有bug，但是互测中被检查出incomplete的错误，前导零的数量规定以及超出的处理情况不够全面，一定程度上暴露了自己思维不够缜密的缺陷。
三、发现别人程序bug的策略
1.第一次的测试任务主要在正则表达式的构造上有一定的逻辑错误，所以bug找起来不是非常困难，但第二第三次的任务几乎没有bug。在互测过程中，首先会逐条测试测试树的结点，进行简单的功能性测试和容错测试，一般来说这样的测试比较全面，但对于认真、细心的同学来说，基础的功能测试可以完全通过。
2.之后会进行压力测试和边界测试，并对特殊情况进行测试，尤其会检查readme的响应是否对应。
3.如果普通的测试可以完全通过，那么可以阅读对方的代码来寻找一些考虑不全面的情况。在阅读别人代码的过程中，可以发现很多自己的不足，并且提高自己的代码水平。
四、心得体会
不得不说完成前三次作业自己付出了很多很多精力，作为一个小白艰辛地挣扎在OO的巨浪中。。。。。。
但完成这三次作业对自己提高也有很多很多，比如正则表达式的学习、list使用、继承机制、接口、方法重写等等，最为重要的是面向对象的思想。虽然现在对于“面向对象”的体会还没有十分深刻，但是在编程过程中已经能够逐渐体会这种思想的精妙之处。这三次的作业也暴露出很多问题，比如INVALID少打V，ERROR少打R。。。虽然及时发现，但也不得不认真反思，吸取教训；再比如代码不够简洁，过于冗长，某些类的功能负担过重，setter和getter方法使用缺少限制。希望日后学习中可以逐渐提高自己的代码水平，也希望可以少些愚蠢，多些思考，如果都不行，就多睡睡觉，多吃吃饭也是好的~