OO第一单元总结
基于度量分析程序结构
利用DesigniteJava软件分析程序结构
typeMetrics 类度量:
秉承着高内聚低耦合的思想，LCOM的值越小越好，FANIN和FANOUT与复用性和复杂度有关，视情况判断好坏。主类MainClass代码行数超过100，LCOM大于0.4，可见主类MainClass内聚不足，耦合过度。
methodMetrics 方法度量:
FactorMatch方法代码行数略多，圈复杂度也略高。这是因为采用递归下降方法，当Term类判断接下来的字符属于因子时，进入FactorMatch，再由FactorMatch来判断到底属于哪种因子（表达式因子、sin因子、cos因子、幂函数因子和常数因子），再有FactorMatch逐个调用下层类，在这个过程中需要很多if-else判断，因此圈层数很高。这样的设计不利于测试和维护，但还没想到更好的方法。
implementationCodeSmells:
designCodeSmells:
一些代码异味，暂没想好怎么改。
类图
bug分析
第一单元中只有第二次作业在互测和强测中被发现了bug。分别是cos函数求导时忘记了负号，和没有考虑cos(x)和sin(x)中可能有空格这两种情况。
前者的修复在表达式中加上负号即可，后者只需在字符串替换时先替换空格再替换三角函数，都是非常简单的bug，应该在自测中被发现。
重构经历
重构发生在第二次作业。第二次作业并不能由第一次较好的过渡，因此选择重构。
重构前：
可以看出圈复杂度较高，模块质量很低，而且最终并没有解决问题。
索性重构，用递归下降的方法解决问题。
重构后：
可以看到重构之后圈复杂度整体降低。
心得体会
当发现现有思路无法解决问题时，可以大胆重构。
先做出一个能跑的程序，一步步来，之后再想怎么优化。
debug时心态要稳定，构造测试样例要细致，不能急躁或者粗糙。
多看讨论区，学习同学们解决问题的办法。
实在解决不了问题就问助教。（