OO前三次作业总结

第一次作业

 

　　作为一个对面向对象、对java完全一无所知的小白，第一堂OO课我听得十分认真，然而感觉就是听到的每个字都懂，合起来就完全理解不了。老师讲的话在脑海里飘了一圈，然后再飞出脑海，不留下一点痕迹。于是课下做第一次作业的时候我就……很懵逼啊！

　　不知所措的我花了一天的时间看“菜鸟教程”速成java，然而准备开始码代码的时候觉得大脑一片空白。硬着头皮把老师ppt上的代码照搬，然后四处求助大佬打开思路。不断的纠结与挣扎中，第一次作业就结束了，成果如下：

 

 

可见基本上就是照着ppt的架构，完全没有自己想法。

整个程序只有两个类，程序入口在ComputePoly中。

优点：1.实现Poly类时有一定的面向对象思想

　　　2.加入try…catch，避免crach

缺点：ComputePoly类几乎完全面向过程，同老师课上总结的共性问题一样，输入处理和业务处理未分离。

 

第二次作业

 

　　虽然有第一次作业练手，但是第二次作业到来时，我依然是不知所措的。在纸上抄了一遍指导书，列出了要求，分析了需要类及其属性，思路似乎清晰了，但还是无从下手啊。最后在大佬的帮助下逐渐踏上正轨，写完以后是满满的成就感（虽然程序很菜...

emmm，Floor就是个摆设

好的，老师上课讲到的本次作业易出的问题，我又中了。这一次把输入格式的判断直接写在了Request类中，所以其复杂度极大……

main依旧是面向过程，几乎所有的类都在main里构造的，抱住菜菜的自己……

 

第三次作业

 

 

　　在第三次作业没有发布时，我还是有所设想的，但是指导书出来的以后，我仍旧一脸懵。过多的文字描述、十分细化的定义和不明确的灰色地带使得我研究了整整一天指导书还是不知道捎带到底是个啥过程。但是吃螃蟹总得下第一口啊，于是我开始总结分析捎带过程的规则，并且将过程中的关系用自己的逻辑来翻译、抽象，最后画出流程图。经过这次作业，我深切体会到了只要算法遵循要求设计严密，程序比自己的脑子要清醒明白得多。

 

　　大概老师最喜欢我这种学生了，每次都是反面教材的典例（手动捂脸）。这次作业最大的问题是，我最后为了图省事，我用了一个极为暴力无脑的算法，高相似度的代码段反复出现，从图中也可以看出就是调度器中的Schedule和Command方法。这直接导致程序效率低下，需要重构算法。一步错步步错，大家一定不要为了一时爽，而为日后埋下隐患。

 

自己的bug

 　　三次作业在互测中没有被发现bug，但第三次作业在自己测试的时候发现了算法设计的逻辑漏洞：在同楼层捎带批处理时，出现了时间顺序问题。后来通过改变请求加入主请求集的方法解决了这个bug。

 

别人的bug

 

• 根据测试树先全面地写一份测试用例，互测时先全都跑一遍，这是较为简单且有效的测试方法，但后期有效性不高。

第一次比较幸运，直接发现了测试代码的一个bug。后两次的测试代码没有测出任何问题。

• 阅读readme对于输入输出等部分的规定和限制，阅读代码，有时候会发现被测者逻辑上的疏忽。

第一次互测通过阅读被测者代码，发现其在分离多项式时先采用 } 分割，从而造成测试用例为 } 时，会输出结果0的bug。此方法有效性一般（很随缘），但是总有些侧重点跑偏的赶脚……

通此类方法在第二第三次作业中均发现了bug。而且，第二次互测，我因为readme逻辑不严谨被报了bug，虽然申诉成功，但是真的让我提高了对readme的严谨性的重视程度。所以，朋友们，readme还是要好好写啊！

• 最后就是重头戏啦，通读代码，构建被测代码设计结构，理解测试者的算法逻辑，寻找疏忽点和漏洞。过程较为痛苦，对我这种小菜鸡看不是自己的代码简直像看天书，完全看不下去啊（当然自己写完再回头看有时候也不知道自己写的啥）。有效性高，然而对我来说可行度很低，我会努力的……

综上，对于目前的我来说，找bug几乎全靠覆盖面全的测试用例。

 

心得体会

1.从开始觉得自己无法完成任务，到在代码中苦苦挣扎，时间不断流逝，不知不觉自己就熬过了一个project。所以要坚持啊，大家一起肝到底！！！

2.OO真的是治好了我的拖延症，让我戒掉了赖以生存的小说。感觉周末写完基础功能，不管有没有bug能不能运行，起码要写完，然后周一周二写测试样例+debug，虽然也天天熬夜，但压力似乎有些许减轻。

3.优化很重要，血的教训告诉我，真的不能犯懒啊啊啊啊！

4.建议大家对着自己的代码好好写readme，不要在这些小地方被扣分。

能看我啰嗦到这里的的盆友，手动笔芯~多线程加油！！！！