BUAAOO-第一单元总结
基于度量分析程序结构
第一次作业
对多项式的求导，Expression类表示一个表达式，其成员变量为Term对象的hashmap，Interpreter用于解析输入字符串，返回一个Expression
(1) 基于度量分析
类复杂度
方法复杂度
可以看到Term.toString过于复杂，原因是在幂函数转化为string类型时使用了过多的if，此处可以进行优化。
本次作业没有被其他同学hack。性能方面，由于使用了hashmap，表达式基本上达到了最短，没有考虑到正负号打头和x**2拆分为x*x等细节
本次作业没有很好的给下一次作业做好铺垫，表达式解析方法过于粗暴。
第二次作业
本次作业难度骤升，因为要考虑表达式因子，第一次作业使用的暴力解析字符串方法骤然失效，遂彻底进行重构。我在本次作业中大量时间用于研究如何递归下降读取表达式。求导本身并不困难，创建Factor接口，sin，cos，幂函数，常量，term，poly均继承Factor，保证每个因子都有实现tostring和求导以及simplify方法。其中，Term是一些Factor构成的List，Poly是一些Term构成的List。在对Poly进行求导会自然向下递归。
Patterns存放了提前编译好的正则表达式
Parser用于递归下降解析表达式
类复杂度
可见Parser中方法复杂度较高，这是因为在解析字符串过程中，我调用了过多的私有方法，此处可以进行模块化优化。
Term中由于simplify和diff的操作过于复杂，整体复杂度较高，此处可以把一些操作在初始化term时完成来优化。
方法复杂度
复杂度较高的几个方法
其中Term的simplify如前文所述，该方法过于臃肿。
第三次作业
本次作业加入了sin和cos内的嵌套已经wrong format的检测。由于和上一次作业的架构相似，仅需调整sin和cos内成员变量为Poly，并且对parser进行进一步递归下降即可。wrong format成为了难点，由于上一次作业的递归下降读取基于表达式正确的情况，这次由于格式可能的错误，我对parser进行了较大的调整，首先对字符串进行多余空白符和非法字符的判断，随后在递归下降读取过程中判断格式错误，包括括号和幂函数的错误。
结构与第二次作业相似，加入了format checker和WF exception
类复杂度
方法复杂度
其中较高的和第二次作业类似
其中getCosFactor和getSinFactor是由于进行了格式的判断，此处重用了相似的代码，可以归类为一个方法进行优化。
代码行数
在前两次作业中，互测阶段没有被找到bug，在个人初期写代码过程中，遇到的一些BUG如：没有及时在while循环中continue，在if判断中逻辑过于复杂导致自己搞错了与或非逻辑，往往正是这类小的失误导致耗费大量时间debug，因此在写程序过程中应该时刻关注代码的复杂度。
第三次作业，互测阶段被hack了两次，问题均是出在格式判断正负号和常数之间的空格时，我的判断条件出了问题，误判了一些正确的格式，自己写wrong format时没有考虑到各种情况，测试不够充分。
对比分析出现bug的方法和未出现bug的方法在代码行和圈复杂度上的差异：在我的前两次作业中自己发生的BUG很明显主要是因为圈复杂度导致的，在第三次作业被hack的这个BUG主要是因为Wrong Format欠考虑。
分析自己发现别人程序bug采用策略
主要采取的策略构建一些我在写代码过程中遇到的容易发生bug的数据点来对别人的代码进行测试，使用python进行核对。
重构经历总结
第一次到第二次作业过程中经历了重构，原因是第一次作业没有留下足够的拓展空间，解析字符串过于暴力，但是在第二次作业理解了如何递归下降进行读取解析之后，重构反而显得思路更加清晰，在这个架构下，第三次作业完成的比较容易。由于重构前后属2次作业内容，没有可比较性，故未通过数据进行对比。
吸取的教训是：尽可能给程序留下充足的可扩展空间，已经写好的类尽量保证其完备性，在拓展时就尽量不去修改了，类之间的保证解耦，方法复杂度尽可能底，如此下来可以保证程序的鲁棒性。
心得体会
第一次作业思维还是比较偏面向过程的，对字符串进行了暴力解析，对象也仅仅停留在所谓的Term和Expression上。
在第二次作业难度骤然增加后，明白了面向对象的重要性，一个接口下的多个类逻辑分明，调用各自的方法，另外，在第二次作业过程中，理解了递归下降的思路，这是一种逻辑非常清晰的做法，为我的第三次作业节省了大量的时间。
第三次作业在格式判断上填了第二次作业留下的坑，更进一步理清了整个程序的逻辑，虽然最后在性能分上没有占到很多优势，但是总体下来我认为代码的结构和逻辑还是很清晰的，代码总计行数705完成了。
