一、基于度量来分析自己的程序结构
第一次作业：
类图:
复杂度：
其中ev(G)即Essentail Complexity，用来表示一个方法的结构化程度，范围在[1,v(G)]之间，值越大则程序的结构越“病态”，其计算过程和图的“缩点”有关。
iv(G)即Design Complexity，用来表示一个方法和他所调用的其他方法的紧密程度，范围也在[1,v(G)]之间，值越大联系越紧密。
v(G)即循环复杂度，可以理解为穷尽程序流程每一条路径所需要的试验次数。
OCavg代表类的方法的平均循环复杂度。
WMC代表类的总循环复杂度。
缺点：没有采用面向对象的思想编程，而是采用面向过程的方式编程，导致在第二次作业的时候代码全部重构。
第二次作业：
类图：
复杂度：
本次作业分析：在第二次作业中，由于并没有事先思考，所以仍旧未采用继承和工厂模式，后来在省视第二次作业时，发现其中xiang类与Sin,Cos,Mihan类即应为父类子类关系，而WrongFormat方法有参数工厂的雏形。因为第一次作业并没有太多坎坷就过了，所以在第二次作业时仍然没有意识到面向对象编程的重要性。
优点：对比第一次作业，已经有了一点点面向对象编程的思想，且为第三次作业留下了可拓展空间。
缺点：仍没有采用面向对象的方式编程，导致代码间依赖度高（这个原因导致了第三次作业根本无法debug）。
第三次作业：
类图：
复杂度：
本次作业分析：本次作业较前两次作业难度较大，代码耦合度更高，这次的代码沿用了作业二的思路，使用Xiang类、Sin类、Cos类、Mihan类、Biaodasi类、Houzui类来记录输入的数据，然而这次在类中出现了一个循环嵌套，即Xiang类包含了其他五个类，Sin类、Cos类包含了Houzui类，Houzui类、Biaodasi类又包含了Xiang类。这样的循环嵌套最终导致了本次作业的失败。原因有一下几个：一、循环嵌套导致求导复杂度增加，最终现了CPU_TIME_LIMIT_EXCEED的报错，这样的报错在这种耦合度极高的代码中根本无法修改。二、因为在个人解题的过程中，是从后往前解题，导致在上述六个类中出现了许多多余的方法。三、因为解题过程颠倒，导致处理初始数据一处也出现了大量差错。
二、分析自己程序的bug
第一次作业在最终答案为0时，会多输出一个空格，导致输出格式错误，此错误出现在重写的toString()方法中；
第二次作业无法处理“+-+”此符号情况，会导致无法将输入数据转换成BigInterger导致错误，此错误出现在WrongFormat中。
第三次作业无论是对输入的处理，还有求导过程的进行，都出现了严重的bug，由于代码间耦合度太高，难以准确定位bug导致此次作业失败。
三、发现别人bug所采用的策略
根据指导书所规定的输入形式编写一个测试数据生成器，生成尽可能长的数据集去测试别人的程序。另一方面，通过记录自己在写代码的过程中所遇到的bug，将此类bug用于测
试其他玩家的程序。还有就是通过极端数据去测试别人的代码。
四、应用对象创建模式
三次作业都与函数求导相关，即应创建各类函数对象，实现求导过程。具体实现，个人认为，可以将求导设为各类不同函数的接口，并在各类函数间实现继承关系，具体实现可见下图：
应用对象创建模式，可使代码的可重用性大大提高。编写的代码不再是为某一个具体过程而编写，而是为了一类对象而编写。
五、对比和心得体会
三次作业根本没有用到继承和工厂模式，导致代码结构一塌糊涂，完全没有从面向过程编程的思维中转变过来。并且一边思考一边写代码的习惯尤为不好，在题目较为简单时这种方法或许可行，但当问题复杂到一定程度之后，就必须在写代码之前进行认真的构思，将大概的思路理出来，再开始编写代码。