一、第一次作业分析

　　第一次作业是多项式加减法的实现，目的是为了让我们了解面向对象和面向过程的不同，并且慢慢熟悉面向对象。但诚实的说，也许是因为不了解面向对象，或者说不知道如何把一个多项式抽象成对象，我的第一次作业还是用的面向过程的方法，相当于是把c语言翻译成了java，所以其实并没有什么好分析的，我的第一次作业更像是对java语言的学习。　　

二、第二、三次作业分析

（一）度量分析

　　（1）Class count metrics

  

　　（2）Complexity metrics

 

 

　　（3）Dependency metrics

 

 

　　（4）Chidamber-Kemerer metrics

 

　　（5）Lines of code metrics

 

　　（6）类图

Floor类由于是硬性要求但实在不知道如何利用所以只是建立了但是没有真正利用到。

 

（二）自我评价

　　其实在写这篇博客前已经把自己的代码重写了一遍。最初的代码从头到尾写在一个.java文件中，方法和方法之间完全没有联系，重复的代码段也没有剥离出来写成方法，代码总行数达到了近1800行，自己读自己的代码都感觉读不懂且让人看得很烦躁。重写之后代码行数缩到了800多行（也许还是很多但是至少比自己原来的1800行好了许多），没有重复的代码段，全都剥离成了方法，对自己程序的思路理解的也更加透彻了，对面向对象的理解也更加透彻了，总的来说重写还是很有意义的。

　　程序的优点（重写之后）：类、方法分工明确，层次清晰。整个电梯运行过程的思路清晰且正确。

　　程序的缺点：循环嵌套多，调试极其困难，很难定位bug位置。

　　　　　　　　调度器功能复杂，包括同质、捎带的判断都在调度器内，且是边运行边判断，在debug的过程中出现了很多问题，修改起来牵一发而动全身。

　　　　　　　　算法复杂，个人能力所限，总觉得有更好的解决方案但是就是想不到。

 

三、bug分析 

（一）第一次程序

　　第一次程序出现的bug在于+100000应该被判断为一个6位数，符合题目要求，但我将正号算进了位数中。

（二）第二次程序

　　第二次程序的bug在于正则表达式匹配，find()函数是只要字符串内有匹配项就为true，所以((FR,UP,1,0)这种输入也会被判断为正确。

（三）第三次程序

　　第三次程序的bug在于大数的输出，java会自动转化为科学计数法，以及相同楼层的停靠的输出，指令应该按照时间顺序排序。

共性分析

　　感觉自己的bug都不是思路上的问题而是细节上的问题，总是遗漏一些细枝末节，主要还是因为测试样例没有编写完全且有的时候自己会犯懒而不去测一些小数据。

四、找bug策略

　　第一步，用自己的数据针对分支树上的所有分支进行测试（一般不会出问题）。　

　　第二步，用大数据测试，条数多，数字大。对细节测试。

　　第三步，快速读别人的代码，主要注意逻辑判断和数组的大小，观察是否有逻辑漏洞和溢出、死循环等问题。

五、心得体会

　　看指导书、看指导书、看指导书。

　　看git讨论、看git讨论、看git讨论。

　　重要的事情说三遍。

　　前期的准备、设计工作的一分钟抵得上后期编写、debug的十分钟！千万别急着下手码代码，先看指导书理解清楚自己到底要干什么，思路要清晰，画一下思维导图，设计一下程序流程，用简单的样例跑一边自己设计的流程，然后去git上看别人提的问题，用别人的问题再跑一下自己设计的流程，把别人提出的注意点都记下来，确定这些没问题了之后，在开始码代码，其实如果能把指导书看明白并且解决完git上的所有问题，你的程序应该就不会有太大的问题了。

　　能在码代码之前解决的问题千万别留到码完之后解决，不然到时候debug这里填一块那里补一块，代码会非常难看并且会时时刻刻有想删了重写的冲动。

　　测试样例要全，要能覆盖分支树上所有分支，测试样例可以分享交流，毕竟众人拾柴火焰高。

　　debug真的要耐心加细心，第三次作业的时候感觉就是这里de完了那里又出来了，而且代码很长，一不小心添补的东西就错了位置，然后又要花好长时间去找，让人烦躁。

　　遇到自己想实现但又实现不了的方法多百度多学习，csdn、博客园里总有解决你的问题的方法。

　　最后。

　　

 

 　　我 鼓励 加油！