前言
暴风雨来临之前总是祥和宁静的，虽然早就知道听说过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构造测试数据，这种方法虽然慢，但很有用，并且能让自己的代码水平得到提高
写在最后
这三次作业只是这个学期要完成的作业的四分之一，然而我已经感觉很吃力了，前方注定很困难，但我希望我能坚持下来, 不断战胜困难，不断提高自己。有些东西，看上去非常非常难，看上去不可战胜，不过只要你用心去做，拼尽全力去做，就一定能战胜它，并且获得丰厚的回报。