OO前三次作业分析

一，第一次作业分析

　　度量分析：

第一次的oo作业按照常理来说是不应该有这么多的圈复杂度，但是由于第一次写的时候，完全不了解java的相关知识，按照c语言的方式来写，完全的根据指导书的逻辑，先写好了正确的方式然后又一步步的判断所有错误的方式，由于没有采用正则表达式，导致代码冗长，写了很多的if else循环导致嵌套过多。执行的次数大大的增加，使得程序的维护十分的困难。

　　类图分析：

第一次作业所创建的类很少，一个储存多项式的类和一个多项式集合的类。所有关于输入的判断全部都放入了一个类里面这就导致了前面度量分析的结果，嵌套过多，而且结构十分的简单，一眼望过去一个类里面300行全是判断语句，让人看起来十分的难受。但是已经能够初步的理解类的属性。勉强能够做到把一个类的属性和他的方法都写出来。通过第一次的作业，完成了java最基础的入门，就是使用类。

二，第二次作业分析

　　度量分析：

　第二次的傻瓜电梯对比第一次的度量分析可以明显的看到，嵌套的使用次数和圈复杂度都变少了，主要原因还是使用了正则表达式，减少了判断输入错误时的判断语句。另外由于指导书的要求，强制要求用5个类来完成任务，但是可以明显的感觉到自己对于类的调度还是十分的模糊，刚开始完全不知道怎么样写出五个类来，脑子里的想法还是过于的单一，面相对象编程的水平还是很低，进行顶层的设计模块始终脑子里还是一团粥，最终还是和舍友共同讨论出了满足指导书的顶层模块的使用方式。

　　类图分析：

　　类图的分析明显的揭露了本次作业的问题，类之间的调度毛病十分的大，由于没有搞明白floor类最终是干什么的，没有加入有关的属性和方法，也没有在别的类中调用他的对象，完全就是一个空的类。而且调度的很简单，单纯的把各个类调度到主函数之中，还是没有解决代码的长度过长的问题，带有主函数的类过于的繁琐，加入了大量的判断，还是不易于维护和修改。

三，第三次作业分析

　　度量分析：

第三次作业，做一个有一点聪明的电梯，感觉难度比上一次的傻瓜电梯不是大了一点点，继承和接口傻傻分不清就算了，关键是感觉写完了以后有成堆的bug，可以很明显的感觉到，圈复杂程度和嵌套的复杂程度又爆炸了，因为实在是写入了太多的判断，多到自己现在也没有想好该怎么样去优化自己的代码，因为在debug的时候是十分的绝望的，经常干掉一个bug，又发现出来了更多的bug，感觉各种的控制变量定义的飞起还是无济于事，最终交上去的代码仍然有很多的bug。可能还是自己在思考这个题的时候没有想到简单的方式，感觉为了处理掉一个bug，只是单纯的解决目前出现的数据情况而去定义一个新的控制变量是完全的没用的，只会平白的加大你的代码量，而去看起来十分的蠢，这次的作业可以说是十分的不满意，仍然有很多地方需要去完善。

　类图分析：

这次的电梯要求使用继承，感觉上继承很像是将父类的东西复制到子类当中，只不过可以不写，而且你可以在子类之中添加新的功能。可以说用继承在一定程度上解决了代码长度过长的问题，因为可以把一部分的程序的分析放入到父类当中，一部分放入到子类当中，而且通过继承的使用可以更方便去调试，不用单步调试一行一行的走，通过调用类的对象能够一下子运行完，看到结果，这样就能够判断到底是父类的函数错误还是子类的函数错误。可以说是一定程度上增加了代码的可读性吧，但是明显感觉自己的使用还是不够的熟练，感觉一定程度上能通过合理的使用类来减少一个类中的代码长度，把功能细分，增加代码的可读性和可修改性。但是自己目前还没有做到，希望以后能做到。

四，自己程序的bug

　　自己程序的bug还是很多的。利用bug树的方法确实消灭了一下bug使得自己的程序能够完成简单的样例，并且通过公测，但是对于很长的数据，就暴露了自己考虑的不周到，没有将多个bug联合起来考虑，一次消灭到底，内心中还是有那种拆东墙补西墙，就事论事，用一个错误的样例只能发现一处表面的bug，但是没有进过自己深层次的思考，思考错误的样例的根本原因和自己程序没有考虑到的地方，这种做法导致了第三次作业bug不断的出现，搞得自己很心律憔悴，最终没有de完自己所有的bug就提交。因而导致公测出现了错误，并且被发现了bug。

五，自己发现别人程序bug所采用的策略

　　发现别人程序的bug肯定还是先看一下对方的程序吧，了解一下他用的方法，看看是否有明显的自己写代码时考虑到的问题他没有考虑到，发现这种很明显的bug，之后就是测试一些边缘的数据，例如输入要求100行，试一下101行，看一下数组有没有可能被爆，看一下数值是否可以超过int类型，这些都是可以考虑的地方。之后就是测一些很大的数据啦，越是复杂的程序，跑很大的程序就有可能因为组合情况的出现而考虑不周出现错误。发现别人的错误代码之后，缩小错误的位置，将bug的真正原因找到。然后让别人心服口服。

六，心得体会

1，将大块的代码分开很重要，不要写在一个函数里面，把各自的功能分清楚，然后写进不同的函数不同的类里面，既有助于debug又有助于别人去阅读代码。

2，debug一定要找到bug的真正原因，不能只是表面的看到了错误就想着只消除这种情况就可以了，这样很容易导致自己前面的逻辑全盘错误，出现更多的bug。

3，对于类的调度有了一些自己的想法，但是明显调度的还不是很熟练，类之间，类内部方法之间的调度还是很松散。

4，如果不想自己在ddl前过于的慌张，交上一份自己不满意的答卷，那就早点开始吧。