一、基于度量来分析自己的程序结构
1.第一次作业
UML类图
OO度量
这次作业我写了3个类，其中class Struct是Polynomial的内部类，这个类有2个属性：coe、index，分别代表每个项的系数和指数；Polynomial类的构造方法用来判断表达式是否合法，其他的方法用来拆分项、求导、获取coe和index，化简、output结果表达式，Dx类用来调用Polynomial中的方法，完成程序功能。
2.第二次作业
UML类图
OO度量
从UML类图中看出，这次作业将许多程序功能都放在的一个类Expdeal里面，这样明显不利于程序的维护，也不利于找bug，还有Expdeal类里面的方法的复杂度也很高，根据生成的Complexity表格看,Expdeal.indexspilt（获取每个项的x、sin(x)、cos(x)的指数）和Expdeal.prin_exp1（输出求导后的表达式）的iv(G)（表示一个方法和他所调用的其他方法的紧密程度）和v(G)（循环复杂度）都很大，再就是这次作业由于没有找到很好的优化方法，仅仅处理了sin(x)^2+cos(x)^2=1这样的化简类型，所以程序性能不是很高。
3.第三次作业
UML类图
OO度量
感觉这次作业的代码结构还是没什么太大变化，或者说没有太OOP，依然是判断合法性一个类，求导一个类（没有优化），由于这次作业的复杂度，导致我因为没有重构使得我的代码复杂度进一步上升。本来是想使用接口实现，奈何对于接口的使用不是很熟练，加上作业时间紧迫，最后还是写成了面向过程。
二、分析自己程序的bug
第一次作业的的bug在正则表达式这一块，通过IDEA的调试，发现了正则表达式的括号使用不当导致匹配出错。
第二次作业中，写完程序后随便输入一个数据，控制台就抛出异常，由于IDEA调试的时候matcher.find()总是返回false，被坑了之后我一直以为是正则出了bug，最后才发现是我判断空字符串出错了，查阅资料后发现字符串为空有2种可能：
str == null || str.equals("")
第三次作业由于嵌套的存在，正则表达式无能为力，处理inputExpression的时候主要以字符为单位去判断，这里占据了我写代码的主要时间，在这块，我是写完这个模块就开始测试输入合法性，也是不断的debug。然后求导那一块我写了几个函数相互调用，通过层层递归来实现求导，这里的bug主要是因子求导返回求导结果时的括号问题，如表达式因子求导返回的结果必须写上外层括号。
我的感受就是，当类以及类方法之间的耦合度过高，单个类方法代码量过大时，程序的debug工作会变得很耗费时间，因为此时程序定位一个bug的范围将变大，调试时会执行大量无意义代码才能到达bug所在处，这将极大降低程序的维护度。
三、分析自己发现别人程序bug所采用的策略
前两次作业我主要是根据自己在写代码时构造的一些测试点来对别人的程序进行测试。
第三次作业由于互测的要求，且程序的输出各异，所以我利用对拍器来对他人的程序进行测试。
我会结合被测程序的代码设计结构来设计测试用例，例如程序中使用的正则过长，那么我会特别去分析它正则的bug。
四、Applying Creational Pattern
从这几次作业可以看出，当几个类（如：三角函数、幂函数、常数）有相同的行为特征时，可以采用Builder模式，定义一个接口来创建组合对象。
代码重构的话，给3种因子分别创建一个类，去实现一个含有求导方法的接口，或者是去继承一个抽象类，从而建立代码的层次关系。