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