前言
“真正的勇士敢于面对惨淡的人生，敢于面对淋漓的鲜血”
我是谨慎拜读了鲁迅先生的名言，怀着崇敬的精神去接触这门课程的。
而当我真的经历了这门课程以后，我才发现，刘和珍君这样的觉悟，我们普通人，果然还是达不到啊....
第一次作业（多项式加减法）
第一次作业，听学长说，是很水的，水到了闭着眼睛写别人都很难找出错，想调试刁难你都很难刁难的地步。
听到这话的我，自然是十分的放心的，毕竟我是早就预先学习了java的，几百行的程序也有所试手，编程能力虽菜，但自认也只是菜狗水平，于大菜狗还是望尘莫及，外加多项式加法不知道写过多少次，随便把一个C的代码拿出来咔咔一改，面向过程的版本就算完成了。
然后，我满怀自信的打开eclipse，想写完了赶紧去玩两把游戏。
再然后，这个周末我就和游戏告别了。
按照预先的设计，我一开始完美的构造出了项，系数，多项式等类，并且为他们的属性尽全尽美的写了调用方法，等到真正写主干程序的时候，发现基本都用不着
因为先前没用过正则表达式，直接就去CSDN上搜了一篇教学，十几分钟就模仿着写出一个像模像样的来了，等到调试的时候用了俩小时才发现那教程写的是不对的，赶紧换一个对照的改，改出了一个一二百字符的史诗长串，结果最后还是没改对（因为这个出了BUG）
看了指导书，我完美的抓住了幂次只能为正的这点，心想那不有符号也只能有正号，于是写了一个超级偷懒的多项式分析算法，结果当学姐在客服群里告诉我-000也是合法输入的时候，我的心情是崩溃的。
到了周三，我舍友告诉我正则可能爆栈，我一想谁这么无聊用大数据炸我，我Catch了Readme还不行嘛...结果发现我自己的史诗长串连大的正常范围内的例子都会爆....于是改改改改改，最后改不了的部分就只能把头扎在北航教书育人的土地上当鸵鸟....
最后果然没写好的部分还是被查出了两个问题，正则匹配写的不对居然没法检测字符‘|’，某些地方多正号不会报错....
第一次作业给我的教训：
1.再简单的东西，设计都是很重要的，设计的可行性固然是第一位，简明性也极为重要，不要有了一种自我感觉对的想法就去写，不然冗余的代码会严重拖累你的思想和程序。
2.用到什么学什么是没错的，照猫画虎也是我们学习的主流，但请务必比对着学明白了试一试再干，不然调试会浪费你更多的时间
3.不要看了指导书的要求就像钻没写部分的空子，否则会被你“友善”的同学用鲁棒锤成棒槌。
4.不要完全相信学长的话。尤其是在自己是菜狗而学长是julao的情况下
PS：
还要以下一些道听途说到的事情....
线性代数很简单，数据结构不用听课，概率统计每年题一样, 操作系统很水....
第二次作业（傻瓜电梯）
为了避免第一次作业的惨剧，这次我提前做了设计，构思了几种方案，脑内估摸了一下，选择了相对最适合这次作业的。
当时我构思的几种策略有：
1.elevator跑时间轴，每0.5一跑，按信息相应（方便后面于多线程接轨）
2.电梯内置在调度系统里，全知全能监控
3.电梯负责运转和记录时间，调度器来控制和发出电梯指令
最后毫无疑问我选择了3，因为1现在写起来的确由于难度，就算完成了多线程的时候也势必要按照要求去重构，二的话可扩展性是在是太差了，而且到了后期的时候调试也会有很大的问题，更是不太符合面向对象的思想。
这次作业由于是气势十足，加上难度也是试手级别，所以完成并没有花费太多时间，主要的难点在于同质请求的判断理解上，而这个问题则再一次像我强调了好好阅读辅导书的重要，如果不能清晰的理解题意的话，哪怕是一个小于号改成小于等于号的举动，都可能导致一整类难以被发现的错误。
在用自己写的样例构造工具进行测试并和舍友互相沟通了理解以后，这次我提前的信心满满的提交了。
然后，结果还是被对面亲爱的同学查出了两个错....
依旧是一个边界情况，是一个样例内很难出现的问题，是一个看到了以后不用三十秒就完全可以改正的小错，然而我压力测试居然没有覆盖到。
这次的经历告诉我，努力是必须的，而完美是永远需要追求的，如果真正想要达到无懈可击，还需要在程序的逻辑结构的严谨性上再下功夫才行。
第三次作业（稍微有点聪明的电梯）
这次作业无疑是上一次作业的承接版，完成的难度很大程度上有上一次作业的用心程度而定。不过从这次作业开始值得注意的是，指导书变得有些不像前两次那么可以直观理解了。
其实依据本次作业的要求，实现方法可以由很多很多种类，但是由于我为了契合指导书以按图索骥，没有采用蜗牛背着重重的壳，一层层往上爬的思想，自己写了一个“执行块”以按头调度，结果在调试的过程中付出了很多的代价。
相信对于以后的作业，单纯弄懂指导书的要求，然后像机器人一样照做肯定是不够的了。理解与转化将是一个非常重要的主题，否则你会发现自然语言易于描述的部分，换成真正一行行代码实现以后，很容易漏洞百出。
这次我跑了很多不同的样例，也接受了舍友很多理解解读的帮助，也正是从这一次我才真正的明白了，发现自己错了然后去改错的被动Debug方法不总是行之有效的，当你想要实现一个功能却需要东拼西凑乃至从新特殊写一个很别扭的方法时，真的没有对自己一开始搭建的策略有所怀疑嘛？写代码开始时设计好固然很重要，而写代码中间适当的停一停反思也是必须的，毕竟，当你程序中需要一行一行敲去判断的特例太多的时候，出不出BUG已经不是你所能控制的了。
尽量减少游离于主体之外，专门为特殊情况服务的语句，做好真正意义上的封装，是防BUG于未然的最好方法。
