一、作业架构与性能分析
1、第一次作业
a、架构分析
第一次作业较为简单，由于第一次接触JAVA，并不是十分了解面向对象的编程方法，所以整个程序的编写更倾向于面向过程。使用了Hashmap的存储容器，以指数为index，每个指数所对应的系数为value，利用map中项的index不能相同这一特点，在记录和简化方面都十分便利。但第一次作业有很大的不足。首先在于程序根本没有扩展性可言，在第二次作业时除了大致框架之外都进行了重构。其次一main到底的编程方法使得代码可读性差且没有一个很明确的结构，这使得程序的可维护性也比较差。
这次作业中直接用Hashmap便能解决大多数的简化问题，除此之外只有尽量使得输出的第一项的系数为正数和不输出系数为0的项，并没有什么难度。
b、性能分析
性能与架构图如下
2、第二次作业：
a、架构分析
第二次作业相比第一次作业增加了对于部分WRONG FORMAT情况的判断，此外还有加入了sin(x)和cos(x)种类项的难度提高。在第二次作业中出于怕麻烦的心理并没有进行大的重构，只是增加了一个记录项的种类的类，配合项的使用来进行求导后项的记录和同类项合并，这次作业中沿用了map来记录项，利用map的特性来进行化简同类项对于这一单元的作业十分简便而不会出错。相比于第一次作业，难点更多地在于WF的判断，在第二次作业中使用了化整为零的思想来判断WF，这为第三次作业中做下了铺垫。
b、性能分析
性能与架构图如下
3、第三次作业：
a、架构分析
在我个人看来第三次作业是悬崖式的难度上升，我认为原因是因为首先在大一的时候数据结构学的不是很好，这导致有关递归方面的知识一直掌握不牢固，第二是第一二次作业的怕麻烦使得第三次的思想，式子的处理完全改变，不熟练的运用使得我反复重构，最后甚至判断WF和表达式求导使用的是两套截然不同的方法，最后也没有时间做优化，所以使得第三次作业的性能分没得多少。但我认为我从第三次作业中收获了很多，从不断的重构中建立了完整而成体系的面向对象程序，更能理解oo的编程思想。
b、性能分析
性能与架构图如下
二、BUG分析
第一次和第二次作业没有出现bug，也没有出现性能分方面的问题。我认为这个给我们的启示是要充分利用JAVA自带的类和容器，在简化代码编写的同时也提高了正确率和稳定性，同样重要的还有不要手搓轮子，这样提高了代码运行的效率，同时也避免了手搓轮子所带来的可能的错误，毕竟人是容易出错的生物，而电脑不是~
第三次出现了bug，因为当时没有时间进行优化，所以不是结构上或者是优化时出现的问题。第一个bug在于当时太过匆忙将常数和系数大于50的情况也算做了WRONG FORMAT，另外一个在于当时对于进行有符号数中间不能出现空格的情况时没有先去掉空格再判断，使得一些WF情况没有被判断出来。但我认为这次作业问题在于根本没有做优化，所以相比于这两个匆忙中写出的bug而言，更重要的是别人出现bug的情况我甚至没有进行过尝试，这是这次作业中一个很大的缺憾，这给我的启示便是以后要提前考虑到程序的可延展性，思考到后期的维护可能性，绝对不能混过一次作业算一次，绝对拖不过去，后期的重构会使你措手不及，从而没有时间进行足够的测试和优化。
三、互测想法
我认为在这一单元的互测中，比起用评测机更有效的是输入极端情况进行测评。此外便是将自己编程中出现的问题编成数据hack别人，比如第三次作业中对于有符号数的处理让我很是苦恼，需要很多的处理来判断符号是有符号数的符号还是加减号，如果不进行好的处理表达式树的建立便很难成功，或者因为少一个符号的计算而得到错误的结果。所以就通过多个加减号和括号的反复组合去hack别人，果然非常起效，一个数据能hack大半个屋，看来己所不欲就施于人在互测时非常好用（不是）。当然评测机也是非常重要的评测手段，但我认为结合自己做题时的困扰和自己出过的bug来去换位思考来构造数据，一般情况下比大量而无意义的测试数据更能起到效果。
四、重构的想法
这次的感想就是如果知道架构不好，就一定要早早地重构，不要拖延怕麻烦，重构是早晚的事情，早点重构就能早点享受清晰而有层次的程序结构，并在后期拓展升级的时候更方便清楚，提高了编程效率，而且OO更多的是提高自己的过程，所以尽善尽美是课程也是我们对自己的要求。
五、心得与体会
这个单元是我们面向对象的初尝试，在接下来的单元中，我们要不断转变自己的思维，由面向对过程到面向对象，同时在接下来的单元中要更重视可拓展性，增强代码的可维护性，在学习OO的过程中不断优化强化自我，希望在接下来的课程中可以更加努力丰富自我，很期待接下来的挑战~