程序结构分析
第一次作业
度量
类图
第二次作业
度量
类图
第三次作业
度量
类图
主方法写在了调度器里，调度过程实际在request，故重构了request
这个构造方法其实还是有部分的面向过程思想，并且电梯类并没有保护到数据。
bug分析
第一次作业：
由于使用了状态机，写的很长很难看，产生了很多bug，改来改去总共提交了七八次。
被公测和互测挂了不少点，也对自己的程序进行了分析，因为开始没有支持多项式最前面的符号，后期时间紧急改了改，然后就把多项式之间的计算搞乱了。特征很明显，符号造成的错误，错误出在输入的类里面，直接导致了后面计算的错误。
程序过于面向过程，有待改进。
第二次作业：
重要的是每天写了一点，时间比较充足，测试也很充分，并没有出现bug，并且保留了测试集对互测程序进行了测试。程序设计还是有些不足，怎感觉类的使用很牵强，没有认识到数据保护的重要性。
第三次作业：
未出现bug。相比前两次作业结构上更完善(虽然依旧很渣)。
分析bug采用的策略
(还是不希望大家丧心病狂，无所谓的错误就放过好了）
(1)使用保留下的数据集，这可以作为一个基本的测试。对于易错的点，相信大家心里还是清楚的。
(2)临界条件一定要测试，一定要测试，一定要测试！！！不论是自测还是互测，临界条件极容易出bug。
(3)如果公测有错误点，分析一下错误原因，也可能找到其他bug。
(4)既然拿到了程序，就看一看大家的程序结构，对于自己写程序有利，也容易发现一些问题。
(5)buggy oo上面的有些数据很好，也可以相互之间对拍。
心得体会
代码风格要好，写清晰，否则后期很难debug。
设计中可以把确定没有bug并且不会频繁改动的部分包装。
写程序前，最好先有个简单的框架构想，或者互相讨论，对一些难点交流下设计思想。
作为并没有系统性学习java的一员，在这几次作业中逐渐体会到了java的编程思想，从第一次作业面向过程，到现在终于像个样子。
The end:
oo群里的消息要常看，大家不时会发个样例，问个指导书上不清楚的点，理解好指导书要求这个程序就不会反复修改多次。
自己有什么问题要及时与助教交流沟通，每个人理解方式不同导致判定也很难去规定。
readme对于自定义的部分要写清楚，个人信息删仔细。
希望大家能在后期的学习中更上一层楼。