作业1：多项式加减法
作为一名在课前没有接触过java的小白，在第一次作业ddl的压力下，我用几天预习了java的基础语法，就踏上了第一次作业的征程。第一次作业要求我们分别用c语言和java写出程序，让我们理解面向对象编程和过程化编程的区别。但是我的第一次java作业就是用c语言翻译过来的，用过程化思路刚完了第一次作业。
第一次作业用正则表达式来匹配多项式字符串会很简便，但是由于初学正则表达式，需要匹配的内容太长，又担心爆栈，于是直接用计组的有限状态机来分析，每读入一个字符便进行相应的状态转化。最后计算出来的结果再用简单的排序方法进行排序、输出。
第一次作业由于不理解对象和类的思想，基本上用过程化的思路来写，程序只有一个类，所有代码基本都写在了主函数里，没有体现出面向对象的思想。
由于第一次作业采用有限状态机这样比较稳妥的方法，公测并没有错误。但是我在设计时没有分析输入多项式不能超过20个，每个多项式不能超过50个项这一限制，所以当输入超过这一限制时，程序并不会报错，这样被找出了两个bug。所以在设计程序时，一定不能错过任何一个细节，只有分析得足够全面，写出的程序才能万无一失。
互测给我分配到的是一位大佬，代码没有找到任何bug，而且代码写的非常规范，所以我就以学习的心态去分析。这位同学就是很典型的面向过程的代码了，我也从中学到了很多。
作业2：傻瓜电梯
第二次作业难度明显要比第一次作业高，从指导书的长度就可以看出来。由于第二次作业分析起来比较复杂，在写之前，我用了一天来整理思路，包括该怎么按照队列依次执行每个=条指令，如何发现并忽略同质请求。由于第一次作业没有用面向对象的方法来写，导致第二次作业也充满了过程化编程的味道。虽然按照指导书的提示写了五个类，但是基本上代码都写在了两个类中，也没有实现类的封装，对于每个类的对象并没有用private来修饰。
这次作业公测和互测中并没有被找出bug，可能是因为在分析的时候想的比较周到，在测试的时候也根据课件上的bug树逐条构造样例测试了一番。
我测试的同学公测错了一个点，是因为没有处理好int的范围问题导致的bug。这个同学的代码写得很不错，比我的代码少了许多过程化的味道。除了超过int范围这一bug，我并没有找到其他bug。（每次互测都有机会学习大佬的方法）。
作业3：带有捎带功能的单部电梯
第三次作业可以说是血的教训了，由于debug比较晚，匆匆写完readme就交了，没有仔细检查文档属性。结果互测时因为泄漏个人信息，直接被测试者申诉为无效作业。（oj平台看不到对方申诉信息，所以我也不知道哪里泄露了个人信息QAQ）所以在写代码之余，也不能忘记仔细检查文档的个人信息。不然泄漏了个人信息，被申报无效的话，之前的努力也就付之东流了。
这次作业是在第二次作业的基础上增加了捎带功能。本以为这次作业只需要在上次作业的基础上稍加改动就可以完成要求，但是写起来才发现自己之前想的太简单。这次作业由于一开始没有分析到位，导致开始写代码时频频改动。最后在执行完每一条指令后，就重新分析一次需要捎带的请求和同质请求。这种方法虽然很繁琐，但在测试时发现还是挺有用的。
这次作业的和第二次作业一样，也是分为了五个类，和第二次作业不同的是增加了判断捎带请求的方法（这里又出现了过程化的影子）。前三次作业为了赶时间，都没有很好地体现面向对象的思想，在以后的作业中，要仔细规划好思路，尽量避免过程化的代码。
公测时错了一个点，是因为在处理开关门临界时间的捎带请求时，由于疏忽导致没有捎带。这归咎于在构造测试样例时并没有覆盖到各种情况，在分析时也没有考虑到位。互测时被判了无效，也算是一个警示吧。
个人心得
1、在写代码前一定要分析好思路，仔细阅读指导书和issues，充足的准备工作可以让你在写代码的过程中更加高效，也不用大幅度地修改，可以达到事半功倍的效果。
2、克服拖延症。之前的作业一直是拖到周一才开始写，导致写得比较匆忙。如果能提前着手分析，就会从容不迫。
3、注意细节，细节决定成败。很多bug都是在一些小细节出了问题，这些错误很细微，如果不进行覆盖性测试很难发现。如果我们开始构思时就分析到位，并在写代码时井井有条，那我们犯错的几率将大大降低。
4、千万不要泄漏个人信息。