oo第一阶段总结

1、基于度量来分析自己的程序结构    

类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代码规模：

第一次作业：共有两个类——ComputePoly和Poly，其中前者有两个属性和五个方法，后者有两个属性和七个方法。ComputePoly类中parsefault方法规模较大，约占300行，其余方法均大约在30行左右，共有大约400行代码。除去parsefault方法外，其余方法控制分支均在5个以下，而parsefault方法有23个控制分支。Poly类中每个方法规模都较小，大约占10行左右，每个方法均有一个控制分支，总代码规模在70行左右。

第二次作业：共有6个类，同指导书推荐相比多出Main类。其中，调度器类有1个方法，规模很小（仅有8行）；电梯类有一个方法和五个属性，该方法规模很大，大约有200行，控制分支数达到30个，用于计算和输出，该类共计230行；Main类有一个方法，共10行；请求队列类有5个方法和9个属性，每个方法规模均适中，store方法（存储请求）占60行，控制分支数有7个，其余四个返回请求队列方法各占5行，共110行；请求类有3个属性和8个方法，每个方法大约占10行，共130行。楼层类未使用。

第三次作业：共有7个类，同指导书推荐相比多出Main类。其中，调度器类有5个属性和1个方法，该方法共4行，该类约20行；电梯类有四个方法和两个有效属性，每个方法大约占10行，该类共40行；Main类有一个方法，共10行；请求队列类及请求类均与第二次作业类似，代码量及逻辑未有较大改动；继承调度器类的超级调度器类共有16个属性和6个方法，除了parsecatch（分析当前指令的捎带指令序列）方法，其余方法均在50行左右，控制分支个数大约在5个上下，parsecatch方法有350行，有42个控制分支，该类共620行。

第一次作业度量分析及类图：

类的内聚性较强，但相互间的耦合性较差。

第二次作业度量分析及类图：

类的内聚性较强，耦合性一般。

第三次作业度量分析及类图：

 

类的内聚性较强，耦合性较差。

总的来说还是因为思路是面向过程的思路，导致某个类的某个方法基本把所有事就做完了，所以出现上面的分析结果。

2、自己程序的bug

第一次作业：未通过压力测试的公测。该bug产生原因是我对多项式之间可能有的符号数估计错误，导致存储符号的数组没开够，少开了一个，因此导致程序异常，与程序设计结构无关。说明开数组时不应过多吝惜内存，应适当使用“土豪式开法”，比如多项式个数不超过20个，那么我可以用大小为30的数组，可一定程度上增加程序的鲁棒性，同时，应谨慎处理分类树中边界测试的情况。

第二次作业：被互测发现仅输入RUN后无输出、数字前导零多余java中String长度时会导致程序异常的bug。这两个bug其实与程序逻辑无关，是因为我的Readme写的过于随意，没有对上述两种情况作出说明，导致极容易产生歧义（但这里我觉得不爆Java中的数组长度）。

第三次作业：暂未发现bug。

3、发现别人程序bug所采用的策略

第一次作业：我采用的测试策略为根据分类树构造数据进行测试，可以保证测试到分类树中所有情况。同时，我通过分析被测者代码发现其作者并未使用正则表达式来规范输入，而是穷举各种错误情况，很容易出现数组越界情况，因此我构造了很多开头及结尾输入错误的样例，并在一个结尾输入错误的样例中造成其程序crash。

第二次作业：同样根据分类树构造小数据进行测试，同时构造了多组100条的随机数据，未发现别人bug。

第三次作业：同样根据分类树构造小数据进行测试，同第二次作业，我也构造了多组100条的随机数据，检测到该程序逻辑上并无大问题。与第一次作业类似，我分配到的测试任务并未使用正则表达式检测输入，因此我也构造了很多含有前导零和正号的合法输入及其它非法输入，并在一个楼层和时间均含有正号的合法样例中造成其程序运行错误。

4、心得体会

作为一个纯小白，这三次作业可谓是历经千辛万苦才做完，并且debug用的时间比写程序的要多上一倍还多。但同时收获肯定是有的。且不论对Java中对象继承、接口的使用，单就设计和debug这两方面我便受益匪浅。这三次作业做完，我觉得还是在用面向过程的思维写程序，每个作业中我都有类规模不均匀、某些类毫无用处的现象出现，但也算沾了面向对象一点边，比如在程序中一定程度地体现了类与类之间互相不透明的特性。这三次作业下来我最深的体会便是bug是永远改不完的，任何一个程序都不能绝对地说没有任何bug；同时一个好的设计会让你事半功倍，具体实现方式比如思维导图等都很有效。关于评价方面，我觉得既然互为同学，应该手下留情，更多地关注和告知别人设计、程序、思路上的错误（如建议他人改用正则表达式等），而不是死盯着Readme中的微小漏洞不放（当然，Readme没写明白的该扣还得扣）；但同时作为测试者，也需要对被测者负责，尽量多看看被测者的程序，如果有bug应如实上报，最好告知对方此bug出现的原因，这样测试者学习了被测者的程序，也得到了分数，而被测者得知了自己程序的bug所在和修改思路，对双方都有好处。最后，祝愿同学们学有所得，心满意足地结束oo课程，也希望同学们评价时公平公正，不要伤了和气。