前三次OO作业总结
前言
暴风雨来临之前总是祥和宁静的,虽然早就知道听说过OO的名气,但是没有亲身体会是无法感受那种气氛的。去年寒假放假前,我特地向学长打听了一下OO的课程简介,只听学长感慨,OS还算简单,OO那是真的坑啊!瞬间心都凉了半截儿。于是带着两本厚厚的《JAVA核心技术》回了老家,打算寒假笨鸟先飞一会儿,将起跑线向前推一点。可是,假期的Flag说倒就倒,回到家里,开始忙起了冯如项目,渐渐的就忘了还有OO这回事儿,结果所有人都应该能猜到的,两本《JAVA核心技术》又崭新的带回来了。然而,此时我还没有受到OO的惩罚,依然和那些寒假苦学JAVA的同学们一样,至少外表上一样,准备着开学的一些琐事,一些都显得平和。然而,该来的还是要来,第一周的周五,OO在一点招呼都不打的情况下就来了,打得我措手不及。我们作业拉取和提交都是在git上进行的,然而,对于我这个之前从来没有听过Git的小白,一切都是那么新鲜和好奇,正好OS课也要用Git,于是便硬着头皮学了Git,知道了解了Git,才知道原来提交代码这么方便!还来不及高兴,已经周一了,DDL即将来临。
第一次作业
第一次作业是项式加减,但是难点只要在多项式格式的判断上,指导书中推荐用正则表达式,啊哈,又是一个从来没听过的东西。看了一个下午,没看懂,用正则匹配时总是有奇怪错误,对于一个新手犯错也是正常的。但是,周三就要交了,唉,没那个本事就不装13了,用起了笨方法(去年计组P1时学的有限状态机),我和状态机是老冤家了,去年就是因为它,让我P1挂了两次。不过现在在OO里遇到,不免还是有些故人般的感觉,毕竟我的第一次作业还要靠它呢。理清思路,13个状态定义好,画状态图,编码,终于在周二到来之前完成了多项式加减的初稿。看着各位大佬都是用正则表达式,我这个用状态机的小白默默地不说话,不过虽然艰难,第一次作业总算完成了。不过第一次作业代码真的丑啊,应该算是面向过程的JAVA吧(?或者是披着JAVA皮的C)
以下是类图和复杂度分析:
看到了很多复杂度为红的方法,现在分析起来,应该是设计时将很多功能都放到一个方法中,没有做到雨露均沾,导致一些类代码过于臃肿,这也给后来的调试带来了巨大的困难,这个缺点在第三次作业也充分体现出来了。
BUG分析:第一次作业我的代码暂未发现BUG,我测试的那个同学可能和我一样是个新手,但是却用了自己不熟悉的正则表达式,这种敢于挑战新事物的精神是值得肯定的,不过也带来了严重的后果,我构造了一个很大的数据,他的程序直接Crash了,仔细分析了一下,是因为正则表达式匹配导致爆栈了,由此可见,Try-catch是多么重要,至少能让你少扣两分。我还发现了一个关于多项式数量限制的功能点他没有实现,也导致了他的扣分。从这个bug我可以总结出,细心阅读指导书的重要性。无论时间多么紧,一定要细心阅读指导书,起码在写代码时要知道自己在做什么,而不是一顿乱写。
第二次作业
第二次作业是傻瓜电梯,比起第一次作业难度提高了一个等级,虽然电梯傻瓜,但是难度并不低。这次作业让我明白了一个最大的道理就是要提前合理规划代码布局,就像盖房子要提前画图纸一样。如果没有图纸,房子盖一半发现盖错了,又要推倒重来,这是对时间和精力的一个极大的浪费。
这是第二次作业的类图
这是第二次作业的复杂度分析:
从图上看,我第二次作业的复杂度比第一次作业算是进步了吧,因为我按照老师的规定,将代码按照功能放到几个类里面,而不是仅仅放到一个类。
BUG分析:第二次作业我的代码暂未发现BUG,我测试的那个同学也是很厉害的,我自己用Python生成很多奇奇怪怪的数据都过了,所以第二次作业我并没有发现对方BUG。其实OO互相测试有个最大的优点就是我们可以欣赏一些优雅的代码,从而提高自己的代码水平。我就这样,欣赏这位巨佬的代码整整两天,感觉真的思维严密,代码优雅,不免自愧不如!
第三次作业
第三次作业是我永远的痛啊,我成功的成为了别人的大礼包,这次作业是在第二次作业的基础上加上捎带请求。在看到指导书的那一刻,我整个人都懵了,感觉逻辑好复杂啊,内心不禁萌生出畏惧之情。然后周末就是整个懵的状态,看讨论区的帖子,和同学讨论,可是思路就是清晰不起来。最后,我想了一个奇怪的算法,这个算法与老师推荐的完全不一样,我自认为这个算法可以完成这次作业了,便勇敢的放弃了老师推荐的思路,没想到从此跌进大坑里。在码代码的过程中,不断冒出各种奇奇怪怪的BUG,我还以为是某些地方没考虑到,就不断的打补丁,可是补了这个地方,那个地方就出了BUG,补了那个地方,这个地方的BUG又回来了,时间就在小修小补中溜走,直到周三,我才明白,是我的算法有问题,小修小补根本不可能解决这个问题了。可惜DDL即将到来,我也无力回天,终于成了大礼包,公测跪了好几个,也被测我的同学抓出三个BUG。这次作业的教训是惨痛的,它告诫我一定不能耍小聪明,要安分守己的按照指导书的要求来,这样才能事半功倍,否则只会事倍功0。
第三次作业类图:
第三次作业复杂度分析:
由上图可以看到,由于第三次作业写得比较痛苦,结构上也比较乱,有的方法复杂度过高,代码显得臃肿。
BUG分析:这次作业我的BUG主要在同质请求和能否捎带的判断上,由于逻辑混乱,这两个点写得比较糟糕,现在我自己都看不懂了QWQ。不过通过这次作业,我得到了一个超级大的经验,那就是顺着老师的思路走,只有这样,才能顺利完成作业,否则自己另辟蹊径,风险是极大的,有时候你认为一个算法没有缺点就并不代表这个算法没有缺点,一旦有,那任意一个缺点都将成为致命的BUG。
我测的那个同学比较悲催,他粗心到输出格式都错了,导致公测跪了很多点,这个错误是不应该的。不过最让我惊讶的是,他竟然和我一样的算法,而且犯的错误也和我一模一样,就这样,我把那些曾经困扰自己的测试点都测了一遍,他也跪了几个点。不过,这次也算我运气好,毕竟拿到的测试程序竟然和自己的思路相似,这样我就可以大刀阔斧的找BUG。这也算是对我整整两天的小修小补的一个回报吧,至少我知道哪儿最容易犯错。
总结
OO这三次作业,对于我这个没有什么基础的人来说,还是很有挑战性的。不过,经历了三次作业的磨炼,我也收获了很多。分为两部分:
1.写BUG篇
a.一定要先搞懂指导书要求啥,在脑子里有个大体思路
b.要规划才开始动笔,否则一切都是徒然
c.如果不断的出现BUG,那就要考虑算法是否正确
d.不要把所有东西都放到一个类里,这样在调试时会遇到很多麻烦
2.找BUG篇
a.先拿自己的测试样例炸一波
b.如果自己想到的样例,对方都过了的话,就要阅读对方代码了。阅读代码时要带着批判性思维,想想对方这么做有什么不好,会导致哪些BUG。然后再根据这些BUG构造测试数据,这种方法虽然慢,但很有用,并且能让自己的代码水平得到提高
写在最后
这三次作业只是这个学期要完成的作业的四分之一,然而我已经感觉很吃力了,前方注定很困难,但我希望我能坚持下来, 不断战胜困难,不断提高自己。有些东西,看上去非常非常难,看上去不可战胜,不过只要你用心去做,拼尽全力去做,就一定能战胜它,并且获得丰厚的回报。