第一次作业
程序结构分析
第一次的作业总体来说比较简单，既然不用判断WrongFormat，就只需把多项式拆分为项存在容器中就可以了，这里我采用了Hashmap<指数，项>的方式来存储。
问题比较明显的地方是类和方法的耦合度过高。导致这样的原因主要有：没有为多项式构造单独的类（解析类等），使多项式的相关操作（解析、求导等）都直接在Main函数内进行；项的ToString方法虽然情况较多，确实比较复杂，但自己的写法不是很良好。导致复杂度过高。
这些耦合度问题的背后反映出的问题是自己在做第一次作业是基本还是面向过程，没有什么对对象的认识，并且没有有预见性的采用扩展性强的结构。
Bug分析
因为第一次作业总体来说比较简单，我自己在中强测和互测中并没有被hack。互测中我采用了针对性样例和自动对拍的方法，找到了一个同学关于合并同类项方面的bug。对于这个问题，如歌采用了合适的容器，将会迎刃而解。但是即使是这样我的覆盖性还不是很理想，2个有bug的同学我只找到了其中一个。
第二次作业
程序结构分析
第二次作业我比较自然的想到了采用四元组的方式来完成对项的存储，构造Hashmap<Index, Term>的容器。实现这点后，第二次作业也没有什么难度了。由于这次作业的WF判断不涉及空格，我就采用了简单粗暴的替换的方法。
可以看到，我的第二次作业的问题所在仍然是面向过程的痕迹过于明显。这方面的问题和第一次作业类似，不在赘述。
关于优化方面，我仅仅只做了ToString相关的优化，即特殊指数、系数，合并同类项，而没有对三角函数进行化简。这个问题我会在文末进行反思。
Bug分析
第二次作业我在中强测和互测中都没有被hack，但性能分自然不是很理想。互测方面我已经完全采用自动化评测的方式，找到了一个同学关于多项式首符号相关的bug，但是类似第一次作业，room中另一个同学的bug我没有找出来。
第三次作业
程序结构分析
可以看出我第三次作业的代码的耦合度已经大幅降低了，已经不再那么面向结构编程了。但美中不足的是没有采用工厂模式的方法，而是集中在了解析类（Parser）中，也导致其耦合度显著高于其他类。
Bug分析
第三次作业由于我时间安排的失误，只完成了一次提交，没能通过中强测。但是代码中主要是有一处比较低级的bug，就是在cos函数类ToString时，本应省略为1的指数，结果不等于判断写成了等于判断，成了省略了不为1的指数。
即本应是：
if (this.index.compareTo(BigInteger.ONE) != 0) {
ret = ret + "**" + this.index;
}
写成了：
if (this.index.compareTo(BigInteger.ONE) == 0) {
ret = ret + "**" + this.index;
}
单元总结与反思
通过将三次作业放在一起进行比较，我也发现了很多自身的问题。
应用对象创建模式
从完全的面向过程过渡到了面向对象的构造与设计，但对工厂模式的应用还不够熟练。
问题总结
1.关于作业的完成。
我的拖延现象比较严重，在作业上投入的时间过少，使得不仅在第二、第三次作业中完成的优化十分有限，也导致我第三次作业的低级bug没能纠正（周六21：47才进行了第一次提交）。
2.关于作业的内容。
面向对象进行构造与设计的能力较差。前两次作业的面向过程痕迹十分明显，即使是到了第三次作业，我的一些类的耦合度也十分的高。
程序扩展性较差。几乎每次作业都无限接近于重构而不是迭代。这个问题也离不开自己面向对象能力较差这一因素。关于类的构造，往往是局限于当次作业，想着怎么方便这次作业的完成（当然因为第一个问题也没有给自充裕的时间进行思考）。
3.关于互测。
我在互测中虽然利用自动评测机来产生大量随机数据进行评测，但是由于我几乎没有详细阅读同room同学的代码，导致没有针对性爆破的评测样例。这个问题主要还是因为我阅读无注释代码的能力有待于进一步的锻炼。
4.同学优秀代码的启示。
通过阅读自己在前两次互测同room同学的代码和课程组在GitLab给出的优秀代码，我深刻的感受到自己面向对象构造与设计的薄弱，也感受到他们所付出的巨大的心血。有些同学在前两次作业就能写出扩展性极强的代码，有些同学在化简上做出了很多的工作，这些都是我难以望其项背的。
问题反思
这一个月来，我认为我的主要问题就是在OO上投入的精力严重不足，不仅体现在作业的完成上，也体现在面向对象知识的学习上。在之后的单元里，我应当在课下多进行一些课堂知识的强化和额外知识的补充，并及时完成作业，有机会的话，积极参与到讨论区的讨论当中。