2021 OO第一单元总结

第一次作业

1.   程序结构分析

　　度量类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代码规模，复杂度分析：

  

　　在第一次作业中，由于自己偷懒，并没有面向对象的思路，而是直接面向过程，在一个类中就写完了本次作业。在MainClass中，方法change是实现对输入的处理，将空格和空白符去掉，处理连续的加减，将**换成^，将**-替换成**.，将-换成+-。在simplify方法中，考虑到本次作业的特殊性，即在一个项中只有x和常数，直接按*号拆开遍历，获得x的指数和常数，求导后输出，在for循环的遍历中又有if-else分支来判断该因子是x还是常数，然后还判断x是否长度为1，之后还进行指数正负的判断，因此认知复杂度，基本圈复杂度等都很高。在youhua方法中，即完成合并同类项的工作，同simplify方法，复杂度很高。复杂度高的原因是因为自己将很多工作都放在一起来做，没有进行拆分。

类图：

 

　　优点：本次作业唯一的优点可能就是我对输入的字符串的处理，考虑到其特殊性，所以打算直接用+分割，分出每个项，所以，先对整个字符串除去空格和制表符，然后对可能出现的两个及三个的加减替换成一个加或者减，因为打算用+直接拆分表达式得到项，所以打算将-替换成+-，这样就能把符号带入下一项运算，又考虑到**之后会有-号，因此将**后的-替换成了.，这样就能拆分出项，又为了将项拆分成因子，所以将**替换为^。

　　缺点：替换的过程比较复杂，容易引起问题，在后续的作业中就因此出现了一些bug。其次是直接对整个字符串进行暴力处理，没有建立出各种类来保存各量，没有面向对象的思路，违背了课程的初衷，方便了第一次作业，但给后续带来了各种麻烦。

2.   自己程序bug分析

       在本次作业中，强测错了三个点，互测被hack了21次，皆是因为自己在优化处理的时候，想把x**1优化成x，便直接简单的用replacAll("\\*\\*1\\","")，即直接将**1去掉，这样直接使例如x**100+150变成了x00+150，这种很低级的错误皆是因为自己当时头脑发热，没有考虑清楚就直接下手而造成的，这也让我引以为戒，在今后一定要想好了再写代码，同时自己也要进行充分的测试。

3.   发现别人bug策略

　　在第一周，因为自身时间安排的原因，并没有进行互测，也有一些遗憾，以后也会安排好自己的时间，不要浪费锻炼自己的机会。

第二次作业

1.   程序结构分析

　　度量类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代码规模，复杂度分析： 

 

　　在第二次作业中，较第一次作业要稍微面向对象一些了，这次使用了三个类Term和TermT两个类的作用都是处理输入的字符串，输出求导的结果，在MainClass中，同第一次作业对字符串进行处理，并把sin(x)和cos(x)替换成sin和cos方便之后的处理。Term和TermT的不同是Term是不打开括号求导，如x*（x），进行求导得到1*(x)+x*(1)，而TermT是打开括号合并后求导，得到2*x，这两个类同样因为把很多的工作放在了一起做，要进行很多的判断，复杂度十分高。

类图：

 

　　优点：考虑了两种方式来进行求导运算，即上述所说Term和TermT的区别，对于一些个别的情况，括号打开将会比不打开求导长得多，而为了缩减这个差别进行优化几乎是不可能的，将一个复杂括号嵌套的式子打开后再合并，几乎不能做到或者很难做到，而一些情况，打开括号又将能远远少于不打开括号，如(x*(x*(x*(x*(x*(x*(x*(x*(x*x)))))))))，如果打开括号直接得到10*x**9，而不打开括号将会是很长的一串，通过采用两种方式，然后将得到的字符串进行长度比较，输出短的那一个，将能较好的解决问题。

　　缺点：类的复杂度太高，还是像第一次作业一样将所有问题集中在一个类中解决，这样不利于拓展，代码的可读性也很低，并且也容易产生各种各样的bug，同时也有很多方法的行数接近60行，各方法的长度普遍偏高，产生bug不容易定位。

2.   自己程序bug分析

　　在本次作业中，在对()的处理中，由于自己的疏忽，将“(-(”将括号之间的-给处理掉了，导致输出的答案错误，如(-(x))，将会输出1，其次也同样出现了类似第一次的问题（罪该万死），在优化的时候，原本想将1-1*x此类优化成1-x，又是简单的将-1*替换成-1，没有考虑x**-1*x这类情况，从而导致了错误。出错的地方复杂度都很高。

3.   发现别人bug策略

　　由于自己不会搭评测机，所以都是通过自己构造的样例来测试别人的代码，而这些样例的来源一部分是自己在写代码的时候，遇到了不太好处理的地方，卡壳的地方，就出这方面的样例来测试别人的代码，另一部分就是自己构造一些极端的例子，比如多层嵌套的表达式，来进行测试，可能因为自己构造的样例强度不够，只测出了3个bug。

第三次作业

1.   程序结构分析

　　度量类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代码规模，复杂度分析：

　　在第三次作业中，由于之前在肝冯如杯，将作业放到了最后一天来写，时间太短了没有勇气进行重构，害怕来不及完成作业，所以只能选择在糟糕的第二次作业的基础上缝缝补补。直接打开括号的方式不太合适了，因此将TermT删除了，只留下了Term和MainClass，因此也延续了第二次作业的问题，代码的复杂度很高。

类图：

　　优点：这一次作业自己完成得很差，可以说是没有优点吧。

　　缺点：没有进行重构，由于第二次作业的代码本就糟糕，不适合继续沿用，但因为时间原因只能硬着头皮用，所以代码的可读性，稳定性等都十分的差，bug也很多，这也是自己痛的教训吧，不能什么事情都赶着ddl。

2.   自己程序bug分析

　　在用加号连接各项的时候，为了优化，如果求导后等于0就continue，导致出现了如(sin(x)+1)求导后变成了(cos(x)+)，其次就是在判断指数大于50的时候，没有经过其他判断，直接使用了Integer.parseInt，对于一些很大的数如1515154513316，就会出错，最后就是自己没有考虑到sin和cos里面括号没有因子的wrong format，如sin((()))，没有输出WF。

3.   发现别人bug策略

　　由于本次作业完成得很仓促，ddl后仍有两个中测没过，代码bug较多没有进入互测。

重构经历

       在第一单元作业中，由于每一次作业都仅仅考虑了本次作业的需求，没有为下一次作业所考虑，所以后两次作业(按理说)都需要重构，第三次作业因为时间没有重构，我也因此而尝到了苦果，并且，由于第二次作业的重构并不彻底，没有真正细致的拆分，仍然是一个类完成很多工作，这样的重构是无效的，尽管重构很难受，当时不重构将会让下一次需求改变时更加难受，因此，敢于打破，并彻底重构是必要的。

心得体会

       只有真正经历了痛才能明白一些道理，我想我大概就是这样，在第一单元中，因为自己没有太过重视OO，真正感受到了惨痛的教训，不仅是每次写代码时的痛，更是看到强测结果时的痛，没有人心甘情愿当个菜鸡，多说无益，只有放在行动上，从这次的痛苦中汲取营养，在下一个单元努一把力。