第一次作业
(1)基于度量来分析自己的程序结构
类图：
设计了两个类，现在看来这个设计很不合理，把过多的功能揉在了一个类内里，不利于扩展和修改。两个类分别为computepoly类和poly类，computepoly类负责提取出每一个项的字符串并传入poly类，以及负责项与项之间的计算和结果的输出；Poly类则负责提取和存储，每一项的系数和指数，同时接受computepoly类的传入和调用。
度量分析：
Metrics图中显示out方法的McCabe Cyclomatic Complexity即圈复杂度过大。Out方法是负责结果输出的方法，因为在里面使用太多的if-else语句，使得圈复杂度过大。
(2)分析自己程序的bug
第一次作业有三个bug。第一个bug为，当输入全为空白字符时，没有报错。第二个bug为，当作为指数的带符号数字中间出现空白字符时，没有报错。第三个bug为，系数和指数的数据类型设计错误，当系数超过long和指数超过int时，程序直接出错。前两个bug均为未考虑全面格式错误，后一个bug则是设计上的考虑欠缺。
(3)分析自己发现别人程序bug所采用的策略
发现了别人一个bug。通过查看别人程序的正则匹配，发现其并未对除x以外的字母出现报错。
第二次作业
(1)基于度量来分析自己的程序结构
类图：
设计了三个类，在扩展上一次的基础上把输出单独写成了一个类，但设计依然很不合理，computepoly类依然负责的太多，可以把对格式的检查等写在别的类里。三个类分别为computepoly类，poly类和hand类，computepoly类负责格式的检查，提取出每一个项的字符串并传入poly类，以及负责项与项之间的计算；Poly类则负责提取和存储，每一项的系数和指数，同时接受computepoly类的传入和调用；hand类负责结果的输出。
度量分析：
Metrics图中显示，依然是执行输出的方法的圈复杂度过大。Printo方法是负责结果输出的方法，因为在里面使用太多的if-else语句，使得圈复杂度过大。
(2)分析自己程序的bug
第二次作业有一个bug。Bug为，当一个项以*开头时没有报错。这个bug是设计思路上的不严谨。
(3)分析自己发现别人程序bug所采用的策略
发现了别人一个bug。同样是通过查看别人程序的正则匹配，发现其没有对s i n(x)进行报错处理。
第三次作业
(1)基于度量来分析自己的程序结构
类图：
设计了五个类。分别为computepoly类，expre类，term类，factor类，pol类。computepoly类负责格式的检查以及对整体的调用。Expre类，负责表达式级别的提取和求导。Term类，负责项级别的提取和求导。Factor类，负责因子级别的提取和求导。Poly类负责系数和指数的提取，以及部分因子的得到。computepoly类调用expre类，expre类调用term类，term类调用factor类，factor类视情况调用factor类或expre类，即依此递归。
度量分析：
Metrics图中显示，因子类内里，对因子求导的factordao方法的圈复杂度过大，以及对因子进行识别的factorcompute方法的嵌套深度过深。factordao方法因为把多种情况的求导揉在了一起，所以其圈复杂度过大。factorcompute方法，则是嵌套的判断太多，使得嵌套深度过深。
(2)分析自己程序的bug
第三次作业有两个bug。第一个bug为，当一个项以*结尾时程序出错。第二个bug为，当项的第一个因子为-1并省略为-时，-没有被记录。第一个bug是设计上的不严谨。第二个则是因为对判断条件的设置错误。
(3)分析自己发现别人程序bug所采用的策略
发现了别人一个bug。通过构造不断嵌套且为不同情况的表达式。
(4)Applying Creational Pattern
三次作业均采用创建型模式（Creational Pattern）。
总结
在第三次作业中，尝试使用接口，但因为设计和理解方面的问题，没有实现。有一个好的构思和设计，在具体实现过程中，会起到事半功倍的效果。