第一次作业
UML类图
耦合度
简述
本次作业较简单，结构比较单一，只分了表达式类和因子类，耦合度很低。
只要合并同类项即可获得性能的满分。
bug
判了WF忘记删掉就交公测了，导致因题意理解错误而错判
没有严谨地读题，误认为+- x是WF，结果互测被轮番hack。
测试
手动数据：根据题目描述生成了三十几个各式各样的数据。
对拍数据：用xeger生成数据，sympy特值法判正确性，其中正则表达式是通过题目描述严格生成，并找同学进行交流确认正确性的。
对拍：用python生成并处理数据得到标答，批处理文件进行输入输出，再进行比对。
第二次作业
优化前
UML类图
耦合度
优化后
UML类图
耦合度
简述
这是一次近乎完全翻新的作业。在第一次的基础上加入三角函数后，原来支持的功能过少，在学习了面向对象的思想和工厂模式等知识后，引入了接口Item，分别用三角函数、幂函数和常值函数去实现这个接口，让问题更易解决。
同时从上面几幅图的对比可以看到，优化让整个表达式类的方法权重数增加了很多。这是因为我在优化的时候使用暴力的dfs，分四路合并，(f*(asin^2+bcos^2))，(f*(asin^2+b))，(f*(a*cos^2+b))，(f*(sin^4-cos^4))四种情况讨论导致的。
感觉优化还是做得比较到位的（设置最大深度和时间，外加set判重），大部分的随机数据的性能都比较好。可惜没有考虑到有一些点对于dfs造成的情况过多而无用，参数没调好（maxdep调大了），导致大量丢失性能分，最终性能只获得了16.3/20分。
bug
一遍通过，没有在弱测、中测、强测或互测中测出任何bug。
在互测里通过对拍测出了别人的神秘bug，漏掉了一项，不知道为什么，没有参考意义。
测试
同样是分别通过手动和对拍进行测试。对拍的正则改一下即可。
第三次作业
优化前
UML类图
耦合度
优化后
UML类图
耦合度
简述
增加了嵌套，直接递归下降对括号进行匹配即可，直接沿袭第二次作业的架构，稍作改动进行括号匹配即可。问题在于如何优化。
这次最大的失误就是让表达式干了项和因子该干的事情，进行了toString操作，整个体系出现了问题，导致出现错误的几率变大。但好在并不影响正确性。最开始认为这样做可以使得在表达式类中通过对于项的抽象做完所有的优化，但后来想想发现这里其实完全可以对加法、乘法等操作进行抽象，但懒得重构了就没有改。
这次的性能分算法很松，所以也没有做很紧的优化（如x**2( ightarrow) x*x，sin(0)( ightarrow) 0，cos(0) ( ightarrow) 1），也没有做三角函数有关的优化，而仅仅是大概的合并了一下公因式，其中还存在负优化的可能性，最终得到了满分，是在意料之外的。
bug
本次测试在弱测、中测、强测、互测中未被发现任何bug。
互测测出他人的bug如下：输出不合法，xxx*-cos(x)；输出不合法，sin(expression)。
测试
同上两次作业，这次的测试仍旧分为手动和对拍。手动测试构造了大量WF数据，尽可能做到了全覆盖。为了防止WF引起的神秘RE，在main函数中catch了一下异常，增加程序的鲁棒性（当然，能测出使得程序RE的bug均被修复）。
本次对拍使用的测试机制与上两次不同，这次无法直接通过正则表达式生成数据。我采取的方式是，先通过正则生成一堆“基础”表达式，再在基础表达式基础上生成嵌套表达式（新写一个正则，把'#'作为一个因子，然后再用之前产生的表达式套上括号进行替换）。
本次测试的缺陷在于，没有手动生成太多的数据，导致类似(1+sin(x))*(1+sin(x))这种基本数据几乎没有涉及，互测屋里只测出了两个没有其他人hack的同学的bug，而没有测出另外两个大部分人都测出bug的同学的bug。
总结和展望
通过第一单元OO的学习，我对面向对象的理解更加深刻了，也更能够将需求转化成各种类和方法。虽然仍然没有做到很好的高内聚、低耦合，但也是一个从纯面向过程选手慢慢转为面向对象选手的飞跃。
做完这一个单元之后才发现，分享讨论是非常重要且必要的。无论是对于思路的理清还是对于新方法的吸收、对于面向对象的理解、对于数据的生成角度，都有很大的作用。唯一的可惜就是讨论区大部分帖子太水而且显然（当然也可能是个人角度问题），令自己感觉大部分没有价值。
感谢助教组和老师们的辛勤付出，感谢共同讨论、分享的同学，期待OO的下几个单元。