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