前言
第一单元的主题是表达式求导，第一次作业是只带有常数和幂函数的求导，第二次作业加入了正余弦函数，第三次作业又加入了表达式嵌套，难度逐渐提升。总体来说前两次作业还易于应对，而第三次作业做得相对有些艰难。而且这其中还有很多巧合，第二次作业延时到了周三上午，而我在周二晚睡觉前经过本地测试又找到一处致命BUG，一直改到一点才交上；第三次作业一开始中测的最后一个点一直没有通过，周二找了一天本来已经放弃，后来得知作业又延时到周三中午，成功在周三上午找到了那处BUG，并正好用完十次无偿提交次数，终于过了全部中弱测。若不是这两次延时，第一单元的作业恐怕已经崩掉了。
一、三次作业的代码分析
1、第一次作业
（1）类图与复杂度：
（2）程序分析
仅用了两个类。主类Derivation仅包括主函数入口。类Exp中包含一个private属性str[]，它是用来储存项的字符串数组；四个方法，其中Exp()是构造方法，同时进行格式合法性判断和拆项，getLength()用来获得str的元素个数，diff()用于处理每一项、求导并将结果中的同类项合并，pri()用于输出求导结果。
可以看出diff()的方法规模较大，因为这个方法同时具有按情况处理项、求导、合并同类项三个功能，可以将这三个功能拆成两个或三个方法来写。Derivation类约有35行代码，Exp类约有115行代码，总共约150行代码。
（3）优缺点分析
第一次作业我的代码总体还是比较面向过程，基本上按照C语言的模式去写的，面向对象的思想不够深刻。
2、第二次作业
（1）类图与复杂度
（2）程序分析
第二次作业的整体思路是处理表达式后，分别获得每一项的系数、x的指数、sin(x)的指数、cos(x)的指数四个ArrayList，求导时则是系数乘以某一个因子求导的结果再乘以其他因子。
总共有Derivation2、Exp、Diffx、Diffcos、Diffsin五个类，其中Derivation2包含主函数的入口，Exp用于判断表达式合法性、处理表达式并进行求导结果的输出，Diffsin、Diffcos、Diffx分别是对三类函数的求导处理。
可以看出，Diffx、Diffsin、Diffcos三个类中的pri函数（对求导结果的输出函数）代码复杂度较大，因为其中为了简化输出结果，用了很多if-else语句判断指数为0、1、2等以及指数为负等情况。还有Exp类中的getList()方法（用于获得各个因子的指数）也用了很多if-else语句判断三种因子是否省略指数等情况。
另外，Exp中的private属性过多，因为判断表达式合法性的方法超过了60行，我就将三种因子及常数因子的正则表达式写到了类的private属性里。
（3）优缺点分析
写第二次作业时其实并没有完全理清思路，很多方法构造的比较复杂，甚至有为了缩减方法行数将方法内的变量移到类的属性中的草率决定。
3、第三次作业
（1）类图与复杂度
（2）程序分析
第三次作业的整体思路是先将输入的表达式进行递归判断是否合法，然后进行链式求导，其中存在对各种因子求导、对项求导与对表达式求导的相互调用。
共九个类，Main包含主函数入口，Exp用于递归判断表达式合法性，Factor作为父类，Da、Dx、Dsin、Dcos、Dterm、Dexp都是Factor的子类，分别用于对常数、幂函数、正弦函数、余弦函数、项、表达式求导。
可以看出方法复杂度最高的是每个子类中的diff()方法（求导函数）以及Exp中的exchange()方法（递归去括号）和judge()方法（判断合法性），因为其中都用了很多if-else语句判断各种情况。
(3)优缺点分析
个人认为第三次作业还是存在一些优点的，比如我独立完成了递归判断合法性代码的编写。缺点是没有对结果进行化简，我的程序是变求导边直接打印结果的，其中只有一些简单的指数为0、1、2等情况的简化，其它的都是直接输出，还存在很多无意义的括号。
二、三次作业的BUG分析
1、第一次作业
第一次作业强测中有一处BUG，互测没有被找出BUG。
第一次作业本来也比较简单，我也做了结果的简化，包括首项为负时正项提前的化简也做了，本以为应该一百分，结果强测有两个点没过。
这两个点都源于同一处BUG，我在求导之后合并同类项时，忽略了合并后系数为零的情况，也就是说我将系数为零的项也输出了，但本应该只是扣性能分，结果应该是正确的，但我在连接每一项时只判断了系数大于0时添上+号，因为系数为负时输出的BigInteger会自带符号，所以我对于系数为0项的输出前没有加减号，也就产生了类似于x^20*x的不合法结果。这个BUG本质上还是粗心了，只考虑了输入时将系数为0的项忽略，而没将合并后系数为0的项排除。
2、第二次作业
第二次作业强测中有一处BUG，互测没有被找出BUG。
我的求导思路是对每一项的每一个因子分别求导，并将某个因子求导结果乘以其它因子，而我判断了如果某个因子求导结果的指数为0，将其忽略，但我在输出时却无条件地在求导因子外的其他因子前输出一个*号，也就产生了类似于+*x的不合法结果。
还有一点值得一提的是我在周二极限de到凌晨一点的BUG，那就是我在对输入的表达式进行同类项合并时，由于我用了四个ArrayList分别储存每一项的系数、幂函数指数、正弦函数指数与余弦函数指数，我在判断同类项时写成了只要在三个存指数的ArrayList中找到了与当前项各个指数相同的元素，就将系数相加而不添加新的指数元素。但这样假如输入一个x+sin(x)+cos(x)+x*sin(x)*cos(x)的表达式时，就会将第四项判断为之前出现过同类项，而将表达式化简成2*x+sin(x)+cos(x)。所以在判断同类项时，应该判断在ArrayList中是否有当前项的各个指数全都对应存在的元素，如果有才是真正的同类项。
3、第三次作业
第三次作业强测与互测中都没有被找出BUG。
这里分享我当时中测最后一个点死活de不出来的BUG。我在递归进行合法性判断时，先判断括号中的内容是否合法，若合法将括号及其中的内容直接替换为字母x或字母e（换为e即代表当前括号及其中的内容是一个表达式因子）。我在替换时用到了replace函数，但是replace会一次性替换所有相同子串，例如输入的表达式是(x)+sin(x)，我就会在第一次替换时直接将原式替换为e+sine，即认为正弦函数括号中为一个裸的表达式，从而判断为WF。所以应该用replaceFirst函数仅替换刚找到的子串。这里还需要注意的一点是，replace函数替换的是子串，而replaceFirst函数替换的是第一处符合正则的子串，也就是说，在找到一个括号子串（设为字符串s），在用replaceFirst函数式应先将s中的+、(、)等字符前加上转移符，以将s转换成正则表达式再使用replaceFirst函数。
三、互测时找BUG的策略(love and peace)
由于本人很菜，前两次互测时都是先手动输入一些易错数据以及自己写代码时曾经出现BUG的数据来判断输出的正确性，然后就是肉眼debug了，即阅读被测代码的设计结构构造相应数据。这样的策略虽然效率不是很高，不过也能找到明显的BUG。在第三次互测时做了一次伸手党，从隔壁大佬那里整来了一个对拍器，找BUG的效率的确高很多。
四、Applying Creational Pattern
每次作业中都有很多方法有很多if-else语句，其实有的可以拆分成多个方法去写。
第三次作业写的时候对继承的用法还不够熟悉，程序的实现对继承的依赖并不大，也并没有使用接口，存在重构的必要。
另外希望可以通过学习自己写出对拍器。