OO第八次作业
唉这OO我可想好好说两句喽。这三次作业可以说难度相较之前大为提高,感觉一下子从普通副本踏入了精英副本区,多线程是该区boss的共性特质,这无疑给我们这些从未接触过多线程的编程者大大提高了难度。抛去线程安全问题,作业任务本身的实现方式也变得更为复杂,指导书也愈发接近实际开发时的客户需求(说不明白想干什么,要求随时改,做完了再说不满意),实在对初入CS大门的萌新是个不小磨练。幸好,在这三次中,我 杨帅 活着熬过来了,没有无效,尽管付出了氪命般的努力与坚持,但,实话说吧,我感觉学的不亏,收获了不少面向对象编程的方式技巧以及对多线程的进一步理解。hhhh,毕竟,难度大的boss啊,经验给的也多嘛。
作业5 多线程电梯
OO度量
输入判定和捎带判断过于复杂
类图
bug反思
输出处理上没严格按要求,好好看指导书就好了。
有一个捎带有时会有奇怪的未响应问题,经修改后bug复现率很低,之前是线程安全导致的问题。
作业6 IFTTT
OO度量
寻找变化的文件过程应更模块化
类图
bug反思
临交前改了一个点——renamed和path-changed的判定,本来没错的地方硬生生改崩了,唉,切忌临交大改啊。
作业7 出租车调度
OO度量
分派的逻辑过于复杂,我发现自己涉及调度的部分总是容易不规范,这可以有些不利于维护。
类图
bug反思
出现了调度层次上的bug,在车辆少时很少产生,但多车(100辆一起)抢单时容易发生错误,感谢我严格的测试者帮我提前发现它,
对issue上很多束缚表示不满,我以为指导书是我们做程序的根本原则,其他地方,合理且定义清楚即正确。在issue上一个地方一句地加强制要求,很为不妥,这个由于issue导致的bug我的测试者也许没违反什么,但我仍要申诉
申诉到 课程组 说明仅指导书上内容为强制要求 其它地方要求为推荐准则 为止:)
bug 分析策略
多线程的bug分析要采用几近覆盖性的狂轰滥炸,确保其在大量指令下没有错误才能叫正确,我分析bug时一般从简单的基础功能入手,之后再测大量线程并行时的调度方案
心得体会
一 交前不乱改
二 测自己程序要采用大量输入压力测试,而不是,简单测测就算对
三 帮助OO课程组完善指导书制度是我们北航6系人义不容辞的责任担当,希望明年在大家的共同努力下,OO课程越来越好