程序结构和度量分析
第一次作业：
第一次作业的逻辑结构和实现：
-
第一次作业没有非法输入，所以通过传入表达式的预处理（除去所有空格和简化符号），
然后将表达式拆分成项，项拆分成因子，然后储存因子并求导输出。
第一次作业度量分析：
第一次作业UML图：
-
类之间存在挺大的耦合，没有使用接口，举例来说：
生成ExpressionSplitToTerm类的对象时候会直接生成TermSplitToFactor类以及生成若干个PowerExponent类的实例化对象。
第二次作业：
- 第二次作业加入了复合函数的求导，结构上沿用了第一次作业的结构，修改了项拆分为因子和求导的方法。
第二次作业度量分析：
- 在识别得到的因子的具体类型时判断过多。
第二次作业UML图：
- 本质上没有和第一次作业有太多的区别，只是把一个一main到底的代码拆分成几部分逻辑，分到几个类中。造成耦合化严重的结构，给第三次作业的重构埋下了隐患。
第三次作业
第三次作业没能通过本地测试。
程序BUG分析
第一次作业在互测阶段和强测上出现一个BUG。原因是传入的新项和容器里已存在的项合并同类项之后，如果其系数变为0，在合并的方法内会自动删除该项并让容器的尺寸减一；然而在寻找同类项的方法里决定是否添加新项的判断条件是遍历所有的容器项，遍历所用变量等于容器尺寸的时候代表循环结束，可以作为一个新项添入。由于判断条件所用的容器尺寸可能会在倒数第二项的时候减1，最后一项如果恰好与倒数第二项合并之后系数为，0该成员被删除，就会产生最后一项合并后又被当作是新项添加进容器的bug。
通过改写循环结束条件，使用一个不会中途改变的量修复了bug，没有让他延续到第二次作业。
第三次作业类之间的递归调用BUG太多，调试无从下手。
寻找他人BUG
Step1 手动构造一些常用样例、边界样例。
Step2 理解互测屋内其他人的代码结构。
Step3 在一个人的代码身上发现漏洞时，构造与之相关的样例补测其他人的代码。
Step4 循环Step1~3
面向对象模式
感觉没能很好的理解面向对象模式的思想，虽然分了几个类但是更像是把面向过程的几个函数方法分开放到不同的类里面而已。在第一次作业到第二次作业的过程中难度提升的还能够添加功能；在第三次作业递归调用几何倍数增加了以后，就BUG频出，都没能通过一些自己构造的本地测试样例。
对比和心得体会
早一点开始作业应该可以给自己留下更多缓冲的时间。
讨论区里面有很精彩的想法和讨论。
在设计之前想好复用性高的类来设计接口或者抽象类可能可以提高效率和正确性。