OO第一次博客作业
尝试使用Eclipse中的AmaterasUML工具，但是始终安装不成功，所以类图是使用的商业版的IDEA自带的UML Support工具制作。
同理，尝试在Eclipse Oxygen和Eclipse Java Neon安装Metrics报错，使用IDEA的MetricsReloaded分析度量
关于MetricsReloaded：
ev(G)：表示程序的结构化程度，值越大表示代码段越难维护；
iv(G)：方法之间的紧密程度,两者呈正态相关；
v(G)：判断程序的复杂程度，值越大表示方法越复杂，在一定程度上可以看作方法越难维护；
1.第一次作业（多项式加减）
类图：
度量：
第一次作业可以看出，Poly类的getArray方法iv(G)和v(G)两项的值都很大，说明对于方法的抽象不够，这个方法应该可以抽象成几个小部分，这种写法说明程序比较偏于面向过程。
2. 第二次作业（简单电梯）
类图：
度量：
第二次作业的Elevator.calculate()方法的ev(G)、iv(G)和v(G)值都很大，我自己写的时候也意识到了将大部分的调图处理放置在一个方法里面是不合适的，在调试的时候非常麻烦，对于数据的封装性也不好，但是因为第二次作业比较简单，所以也没有进行方法的调整。
3. 第三次作业（ALS电梯）
类图：
度量：
由于前两次没有注意将不同性质的处理方法抽象出来，所以这次将主要的调度还是写在一个方法里面，后期debug的时候出现了很大的问题，也导致了第三次作业的失败。
分析自己的Bug
前两次作业比较简单，所以在程序逻辑设计上并没有太大问题，公测和互测检查出来的Bug都是在细节问题的处理上：比如忘记处理了楼层数字的前零，还有对于同一个错误，输出了两个错误提示信息。
但是第三次作业暴露出了很多问题，导致公测中关于捎带的测试点基本都挂了。
对比分析了自己的代码和公测拿到的大佬的代码之后，意识到了实质问题出在对于面向对象思想的理解和对于程序整体的架构上，比如对于无效输入和同质输入，我的处理都是在具体的代码段使用两个System.out和continue语句，但是因为程序中需要很多这样的判断，所以导致代码出现了大量的冗余，然后在指导书更新的时候，需要在每一处修改细节，浪费了大量的精力。而更好的处理方法如下：
class ERROR{
public static void errorOut(String str, int type) {
if(type == 0) {
System.out.println("INVALID[" + str + "]") ;
}
else if(type == 1) {
str = str.replaceAll("\\(","");
str = str.replaceAll("\\)","");
System.out.println("#SAME[" + str + "]") ;
}
}
}
构造一个错误处理类，使用static修饰类中方法，使用时不需要new一个新对象，需要输出错误时只需要一行ERROR.errorOut(str,type)即可。
其次就是变量命名的问题，比如我最开始使用TIME表示系统时间，而time表示当前请求时间，这种命名方式就很naive，阅读性很差，无疑是给自己debug的时候增加难度，而比如使用curTime表示系统时间，reqTime表示请求时间就很清晰。
分析别人的Bug
找出别人的Bug的方法，无非就是阅读别人的源码和使用自己构造的样例。
前几次作业中和室友协作，使用在线文档的方式根据分支树构造了比较完成的测试样例集合，所以在测试别人代码的时候比较有用。
第一次作业比较简单，找到两个Bug；
第二次作业对面公测挂了10个，同质挂了一堆；
第三次作业，拿到一个大佬的代码，虽然没有找到bug，不过阅读源码也颇有收获。
心得体会
- 代码在一定程度上是越精简越好，冗余的代码维护起来十分费劲；
- 对于面向对象思想的理解：将功能相同的模块提炼成类以及方法；
- 总结来说就是写的代码太少，对于面向对象的练习不够。
