一、程序结构度量与分析
对前三次作业，我借助IDEA中现有的工具，分别得出了它们的UML图和复杂度分析，如下：
第一次：
第二次：
第三次：
很明显的可以发现，我几乎没有使用继承、接口，主要原因是在开始第一次作业时继承、接口等相关内容还没有吃透，不敢贸然使用，当然这只能怪我寒假的时候没有好好用功，第一次作业时我有意识的去使用面向对象的手段，但写完之后，重新审视自己的代码，发现不过是一些新的容器、函数的封装与分类罢了，比如有些类里面仅有一些方法而没有成员变量，我想要重构，但是时间却不允许，到了第二次，我发现和第一次的思路大体上是一致的，不过是将项的形式变得更加复杂了，等价于除了x以外增加了sin(x)、cos(x)和一些新的求导运算罢了，于是我简单的在第一次的代码基础上稍作修改，很快实现了功能，大的架构还没没有动，第二次比较复杂的是性能的优化，对此，我在基本上算完之后，建立了两个方法来进行优化，至此我的程序看起来还是面向过程的居多，到了第三次，我以为看来是不得不重构了，最终呢，我还是保留了第二次的代码，并没有所谓的重构，在第三次的作业中，我一下就发现了这次的作业的难度与复杂度，这时我告诉自己要先做设计，在经历了两三天的设计之后，最终选定了一个基于字符串递归的方式，每得到一个对象便分析其属于哪个对象，进而求导，直到完全算完，这时需要保留第二次作业的计算手段，因此我保留了第二次的代码，将其封装成一个方法，以对满足形式的对象求导，这第三次作业稍微有一点面向对象的意味，但是就代码来看，有些杂乱无章，大体给人的感觉就是很多方法封装在了main里面，我觉得呢，就思考的角度来看还是有些面向对象的味道，另外第三次这种算法在性能上有着天然的优势，写起来也较为容易。总的来讲，代码面向对象的特点没有写出来，写作业时仅考虑了课程组的要求，代码不优美，对后面需求的前瞻性不够。代码的耦合性还是比较低的，当然这都是对于单独的方法来讲。
二、我的BUG
第一次：
第一次作业不容易出现BUG，在简单的调试之后代码顺利的通过了公测、互测的考验
第二次：
第二次作业中稍微复杂一点的不过是优化的方法，写完之后有些不自信，经过简单的调试，还是没有发现问题，最终也成功的通过了公测、互测的考验
第三次：
第三次作业前期的思考、设计过程消耗太多时间，最后自主测试做的不够，当然这也怪我自己没有考虑完善，最终在公测、互测中都被测出了BUG，当然思考和设计同样是必要的，这次的BUG出在最开始的算法设计上，在对表达式进行项的拆解计算时，我提取到第一个连接项的符号时便将表达式拆解开来继续递归计算，但是这在数学上是不对的啊！！！是一个小学生的经典错误，简单来讲就是（1-1-1）与（1）-（1-1）是不一样的啊。。。在自主测试的环节中，我针对性的构造了很多样例，但是样例的数量和随机性是不够的，以至于这样容易发现的错误竟然没有被发现。这种算法的错误是很难通过看代码自主检查出来的，因为代码和算法之间的映射是对的，总的来讲还是测试不够。
三、别人的BUG
第一次和第二次互测时，我都是通过构造一些边界的数据点来对别人的代码进行测试，感觉面对6、7份代码时很难静下心来好好看别人的代码了，第一次屋里仅有一位同学在一种特殊的情景下会出错，在处理项的加减号时没有考虑清楚，第二次别人的BUG稍微多一些，我也是直接用一些简单的测试点进行测试，其中有一个同学的代码仅在sin(x)2+cos(x)2的时候才会出错，可见对边界的测试很必要的，我也用这样的方法发现了2、3个别人的bug，第三次的时候结果较为复杂，我利用python构建了一个简单的答案对比器，在一次性想好所有的测试数据之后，用他们的代码来两两对比，简化了工作，当然我也针对性的想了一些边界的数据，其中一位同学在出现多层括号嵌套时会爆栈，格式判断时使用的正则表达式会溢出。
四、应用对象创建模式
关于对象创建模式的说法我第一次听说也是在第一次作业的讨论区，当时我已经写好了代码，回头来看我发现我已经有点意识到类似工厂模式一类的思想，对此，我觉得更应该运用这个的应该是第三次作业，第三次作业我偏重对算法的考虑，偏重对过程的考虑，其实也像是一种建立工厂的思想，是否可以考虑在判断因子、对因子作计算的时候都整合进因子工厂呢，虽然看起来本质上是一致的，但是将工厂整合起来，其代码的耦合性更低，而且利用抽象类给出一些抽象方法可以一定程度上减少代码的冗余部分。
五、对比和心得
通过对比别人的代码，我发现自己的代码真的可以用一团糟来形容，我觉得有以下几点值得今后注意：
命名
我的代码中命名规则真的是太差了，很随意，甚至常用拼音，这真的是很不好的习惯，大大降低了代码的可读性，今后一定要克服，看到别人漂亮的代码，我才深知这个命名的重要性
架构
有的同学包括我也总是觉得作业比较偏向过程的设计，当然这从我的代码里也可以看出来，直到看到大佬的代码，漂亮的对象设定、方法的整合，将整个作业拆分成一小块一小块，使得每一处的逻辑都变得比较简单，不仅漂亮也不容易出错，当然这肯定得在写代码之前好好静下心来思考设计，并结合课上所学。
其他
我看到有些同学将相关的类放在一个文件夹下，弄成包，在面对一个很大的工程时，想必这是比较好的。