写在前面
虽然在开学前看过一点点java，但由于是没有目的的胡乱翻，也不成系统，所以虽然发现直到第二次作业课堂上的内容几乎都有模糊印象，但是对于最基础的java语法什么的没有进行细致了解，再加上只是一味翻书没有实践，导致了到第一次作业摆到面前的时候，竟不知道从何处开始码，完全是一脸懵逼的状态。只好把课件上的实例在本地试了又试才终于开始摸到一点门道。
第一次作业
这个图反映了我第一次作业的一个巨大的问题那就是嵌套太多，while语句和if-else条件语句，原因是我把整个计算过程塞进了一个方法里，导致了这个方法极度臃肿而且条件层层嵌套，效率极低，不但在写这部分代码的时候需要极多的考虑，而且在后期调试的时候也为我造成了很大的麻烦。这一点我将引以为戒，也希望同学们能够避开这类问题。
关于心得
首先一定要细心，不要搞清楚了问题，结果写错了答案。在一周不到的时间内自学了java、然后对java内的正则表达式弄得晕头转向，再加上用了几乎是面向过程的想法来强行写面向对象的东西，弄得恍恍惚惚，以至于我在输出的时候多了很多“}”都没有发现，甚至作为结果放在了自己的测试样例上，直到在互测同学bug发现我的样例ta全错才反应过来。造成了很大的麻烦。
然后是好的设计，最初我的想法是用二维数组存系数和指数，再进行排序。在这么做之前室友点醒了我直接用数组的序号作为指数，在对应位置存系数就可以了，这大大简化了我在结果处理方面的工作。
第二次作业
在统计中比起第一次在多个方面都要有所改善，其中 judgeright方法用于判断从控制台读到的字符串是否是一个合法的指令，这是一个和第一次相同的错误，我将过多的判断条件放在了一起，导致了这个方法过于肿胀，这一部分的代码由于最初没有考虑完全以至于最后又花费了大量时间修改。再结合之前那个几乎是面向过程的程序和老师对于第二次作业的指导，我认为，不要让一个程序的工作“扎堆”，要让他们分散细化，这样才能有条不紊地运行。
总结到这里，我明白了总结这一件事情，一定要写下来自己认真分析，而且越早越好。前两次作业犯了相同的错误——将大量工作聚集到同一处，而且在作业过程中明显感受到了吃力。所以总结不能仅仅停留在查看自己的bug，或者就着自己刚刚写完时的感受抱怨或者感叹一番，而是真正要有条理的分析。
然后是bug，这一次是真的惨痛教训，第一次作业时我直接跟着C的习惯用的printf写了
System.out.print(xxxxxx);
System.out.println(xxxxxx);//应该写这个 正好第一次要求同行输出，而且留着第一次的时候报错就退出的心态，这一次仅仅根据要求把退出删去了，也根本没有测有无效指令后跟有效的情况，直接导致了最终一大半测试点爆掉，原因就是没有分行orz，这是一个悲伤的故事orz，惯性思维要不得的。
第三次作业
有了第二次作业的铺垫，第三次作业在思路上还是很清晰的。从图中可以看出，实际上我直接拿了第二次作业的代码，然后用scheduler继承了commander类，现学现卖弄了一个interface总结电梯的运动过程，在scheduler中加入新的方法来让新功能得到实现，不过也出现了很多冗余的代码，这个需要更加熟悉继承的写法，做好优化。
直接拿第二次的代码修改的弊端在这一张图上体现的很全面，这一次的代码继承了第二次代码的缺点并且“发扬光大”，就不再重复说明了orz。
第三次的作业在第二次的基础上“升级了”功能，认识到这一点很重要，然而我在写代码的时候没有注意到这一点，造成了最后在调试时困难重重。由于是功能升级，所以功能实现过程就应该开始改变，而不是直接往里面加东西。就好比一个凳子腿坏了，应当替换一个新的，而不是在这个坏的腿周围加一堆板子固定。也许加东西最终结果可能一样，但极其费力，而且不够可靠。如果是完全不相关的新功能，直接加东西应当问题不大，但是要升级旧功能，就应当从结构上进行修改和优化。
关于bug，也就是上述问题，导致了在写的时候一团浆糊，有一些没有考虑全，相当遗憾。
体会
1.很难，没用过Java的萌新直接开始了3周的OO，尤其在第二次作业的时候明明花了那么大精力好不容易写完了，结果在最简单的地方出了错，直接导致大半测试点爆掉，差点在第三次作业就想随便把第二次的再交一遍不再改了不再管了。最终还是没有放弃，虽然有一些地方不够完善，但终究成功做出来了。
2.好的设计会大大减少工作量。有一个分工明确的条理清晰的设计可以在实现过程中让思路清晰，可以让调试的时候也变得轻松。
3.坚持下来。