OO第一次课程总结
一.度量分析
第一次的多项式计算的类分析图
第二次作业和第三次作业的差别不大, 以第三次作业为例
第三次作业的类分析图
耦合度分析图
从分析可以看出, 复杂度最高的类是调度器ALSScheduler, 即电梯的调度算法都写在了这个类中, 使得复杂度特别高, 代码的可读性也不高, 显得非常混乱, 代码中也有不少重复的东西没有封装成函数.
二.bug分析
1.第一次作业的公测和课下互测都没有测出bug.第一次作业的重点放在了对输入的检查上,代码整体的逻辑显得不太复杂, 所以bug较少
2.第二次作业的课下测试中, 被同学找出了一处bug来, 在客服群中要求请求超过100条的自行处理, 但前100条一定要处理, 我没有注意到这一处细节, 我的程序在超过100条时会报个错就直接结束, 导致被报了个ERROR.
3.第三次作业在课下测试中, 被同学找出了一处调度算法上的bug, 在电梯的运行过程中, 我是按时间粒度为0.5s进行循环模拟的, 在同层的捎带问题上出了问题,错把电梯开门时刻发出的请求当成了同质请求给处理了.这个bug从侧面反映了我编写的scheduler的逻辑比较混乱, 对电梯一些细节上的问题拿捏不准确, 在调试过程中产生bug, 对代码进行修改时, 没有理清思路, 导致代码复杂度越来越高, 也没有加上合理的注释, 导致代码可维护性非常差.
三.课下评测他人程序
评测他人的程序其实和评测自己的程序的重点其实都是一样的, 其中包括:
1.最基本的输入测试, 对文档要求的一些最基本的样例的测试
2.边界数据的测试, 例如电梯中时间的上限测试, 楼层10楼和1楼的测试
3.程序的压力测试, 测试比较大的输入是否会导致程序的crash
4.错误输入测试, 一些格式不符合规范的输入是否能检测出来并且报相应的错误
5.一些逻辑比较复杂的情况的测试, 例如电梯中一些同层请求何时判同质, 该按怎样的顺序执行输出, 这里是最容易犯错的地方, 并且bug的隐蔽性也特别高, 不太容易发现, 有时候只有去通读代码, 去理解代码的逻辑才能发现这类错误.
四.心得体会
通过这三次的作业, 感受到了OO这门课的难度还是不小的, 相对于上学期的计算机组成原理, 这门课的要求更加宽泛, 文档中的一些要求不免会存在着许多的歧义. 很多东西都要自己去反复阅读去理解.
每次的作业大致分为三个步骤:
1.详细的阅读指导书, 并积极的去思考某些可能会出现问题, 容易犯错的地方, 理解指导书的要求.
2.去构思整个项目的具体架构, 应该设计哪几个类, 这些类分别应该包含哪些功能, 又是怎么联系在一起的.每次的项目我都要建一个Exceptions的类,
将异常进行大致的分类,在代码中遇到异常时就抛出相应的异常, 交由最上层的Main函数去处理这些异常. 后两次作业的最烧脑的地方就是调度器该怎么写了
两次的调度器写法
3.第三步就是代码的实现了, 后两次作业来说, 最麻烦的就是scheduler部分代码的实现了, 虽然构思的时候认为自己想的已经很完善了, 但是写起来之后会发现更多之前没有考虑到的东西. 在写的差不多之后,再把其中重复度高的部分封装成函数, 也将调度的过程划分成几个小的部分, 使得代码的可读性更高.
完成代码后就要去测试了, 去构造一些特殊的数据去测试程序是否按照预期的去运算工作.第三次作业的调度器写的比较失败, 代码的太过复杂, 不够精简, 导致debug的时候特别费劲, 都忘了当初自己写的是什么意思, 而且de完一个bug, 还可能会导致其他错误的出现. 使得代码逻辑更加复杂. 下次希望自己能将代码更精简一些. 并提高代码的函数化和模块化.
