怀着忐忑的心情和之前了解过Java的“勇气”选了这门课，于是糊糊涂涂的开始了我的OO之旅。
结果还是很客观的，总的说来，第一次作业因为比较简单做的还行；第二次在调度器上犯了一些致命的缺陷，自测的时候又不是很充分所以错了很多；第三次作业完全被Crash掉，究其原因还是因为第二次作业中的BUG加上下来没有认真总结失误的原因所致。
1.多项式加减
1.1程序分析
第一次作业的逻辑整体还是很清楚的。因为功能比较简单，类与类之间的层次和关系比较清晰（对象是多项式，动作是加减运算，最后输出结果。大体上是按照这三个流程来写的，加上对Java的构造函数有一些了解所以通过调用类来实现一些函数的功能就很简单了），所以写起来也不是很难。公测唯一的BUG是出在输入检测上没有对正则表达式进行爆栈的处理。
1.2BUG分析与心得体会
互测出现了一个BUG：关于如果输入一些非法字符(对于指数为‘-0’的情况)。虽然后来协商的时候我以README中自定义为由申诉成功，但是现在想起来实际上是对正则表达式使用不熟练导致的结果，从一个侧面吐槽一下我的学习能力（这个‘BUG’一直被带到OO的实验课上对输入的字符串进行处理，最后也是勉强过关。。）
总之，以前接触的Java和所谓面向对象的编程都一直停留下简单的代码层面（都是解决一些很简单的数据结果问题），但是这次作业算是第一次按需求写出来的比较实用的程序了，还是很exciting的。不过因为没有对自己的程序潜在BUG作出正确判断，加上拖延症，导致后几次作业Crash了很多，这个锅我得背。
2.傻瓜电梯类
2.1程序分析
2.2BUGS和心得体会
第二次作业实际上是用时间最长的一次作业，但是效果很不好（这也说明了好的代码和时间没有直接关系，重在思路。
第一次调度器中的思路不对，我构建了两个队列，一个是所有合法的命令队列，另一个是在上一次命令的执行时间内触发的所有命令队列，然后在第二个命令队列中进行同质请求的判断（主要思路是：如果是同质请求便出队列，如果不是同质请求出队列后又一次插入队列，由于队列的顺序所以所有的命令在执行时间上并没有冲突）。当时以为自己发现了新大陆，但是后来公测结束后傻眼了，发现几乎错了一半。。。
算法的逻辑很是复杂，难点主要在如何处理两个队列执行的先后顺序关系上，我几乎是考虑到了所有的情况，分别做了补充，但是现在想起来思路确实是不对的，这样会导致更多的数据共享，而且是类与类之间的，程序不出错才怪。（意识到好的程序应该是之前就应该构建好所有的思路和框架，这样在学的过程中哪里出了问题也可以及时发现，便与修改。
收到的测试对象是一个大佬的代码，他的思路就很清楚，只有一个队列，并且在类之间的关系上处理的很好，让我在第三次作业的处理中基本思路上做了很大的改进。
3.ALS调度
3.1程序分析
3.2BUGS和心得体会
最后一次的作业完全是态度问题了。。
因为没有看清楚指导书的输出细节，以及在issue上的一些细节要求，所有在输出格式上全军覆没，虽然在捎带请求上也有很多的BUGS，但是最主要的错都出在输出上。
关于捎带请求，因为我之前重写了调度器，重新构建了一些类和属性，导致又出了一个比较重要的错误：所有的命令的捎带应该是在该次命令执行之前就被判断的，并且执行也是在该次命令之前，时间上会与本质的不同，这一点在公测面前很容易就被察觉到。
4.总结
好的程序设计应该建立在很多因素的基础上，好的构建，好的数据结构和类，甚至好的输入输出方式都很重要，重在细节的处理上。最后，态度决定一切。。（克服拖延症是永恒不变的主题Orz