天天看点

oo第一次总结

第一次作业

1.度量分析

oo第一次总结

 第一次作业的metrics图分析出现了标红的McCabe Cyclomatic Complexity和Nested Block Depth。McCabe Cyclomatic Complexity表示圈复杂度,而Nested Block Depth表示嵌套深度。标红的McCabe Cyclomatic Complexity表明类之间的职能分配不均匀。因为是第一次写作业,从始至终都只建了一个类,导致了一个类承担了所有的职能,圈复杂度出现了超标现象。标红的Nested Block Depth则表示嵌套现象严重。由于暴力的一次次匹配,不停的用if-else语句和while/for循环语句,导致嵌套很多。

2.类图

oo第一次总结

第一次作业,因为刚刚学习JAVA,对类和对象的概念不熟悉,基本按照过程化的思维去写,所以只写了一个类。在这个类里,进行了所有的操作,导致这个类非常的冗杂。

3.关于BUG

第一次作业,要求用面对对象的思维去看待问题,思考问题,解决问题。但是由于长期的面向过程编程,导致在写本次作业的过程中,很不习惯。第一次作业是多项式的加减法,总体的设计难度不大,但是其中牵涉很多的细节问题。在公测和互测各出现了两个BUG。公测中的两个BUG分别是因为正则表达式过于冗长,导致爆栈和前导零输入太多报错。公测的这两个问题,反应了思考还不够严谨,没有想到会爆栈。互测中的两个BUG则是因为在Read里没有说明嵌套输入会报错,即使实际操作中会当作一个输入错误输出和没有定义输入为{}时,输出什么。互测中的两个问题,反应了没有仔细研究各种输入输出的分类。

而作为测试者,拿到的程序公测全过。所以想到了输入和输出的问题,分别找到了两个问题,一个是只输入{不报错,以及在输入的末尾多一个“,”不报错。综合来看,第一次作业的输入输出是一个难点,很容易少考虑情况。

第二次作业

oo第一次总结
 从第二次作业的metrics图可以看出,出现了与第一次作业同样的问题,圈复杂度超标和嵌套现象严重。因为所写的调度的类中,承担的职能太多以及输入和调度频繁的循环判断。
oo第一次总结

 从类图可以看出,调用关系有点复杂不明确,因为写的时候没有考虑清楚各个类的方法,在写的过程中,强行放入了一些方法,导致最后对类的考虑不明确清晰。在以后写作业的过程中,会仔细明确的划分类。

相比于第一次作业的主要是输入格式的错误,这次的问题则主要是没有考虑到数据溢出的问题,导致公测中与数据溢出相关的两个测试均出错了。而互测则没有被发现BUG。

作为测试者,在拿到的程序中,发现了一个与输入有关的问题,在正确的输入后添加字符,不会报错。

第三次作业

oo第一次总结
 从第三次作业的metrics图可以看出,出现了与前两次作业同样的问题,圈复杂度超标和嵌套现象严重。同样是因为所写的调度的类中,承担的职能太多以及输入和调度频繁的循环判断。并且因为第三次作业是在第二次作业的基础上加入了捎带操作,导致问题更加严重,程序更加臃肿。这三次的作业,都反应了程序封装和代码简洁的重要性。
oo第一次总结

从类图可以看出,第三次作业类的调用关系比第二次作业更清晰明确。但是思路依然有些不清晰,对每个类的职能的考虑需要更详细。

对比傻瓜电梯,捎带问题显得难度上升了很多。因此如果对捎带问题看的不全面深入,很容易出现BUG。正是因为如此,这次公测中出现了2个BUG,互测中出现了4个BUG。公测中的两个BUG,分别是副请求时间==主请求开关门完毕时间不捎带和e.sta==DOWN的部分应该在主请求处理完后,选队列位置最前的成为主请求。而互测中则主要是e.sta==STILL和e.sta==UP问题。这次作业出现了很多问题,反映了对问题分析不够深入,导致程序设计不统一完备。

而作为测试者,此次拿到一个全过的代码,所以从一条条BUG树类样例去测试,但都没有找到这份作业的错误。

心得体会

  1. 到目前,写了三次作业,对面向过程编程和面向对象编程的区别的感受仍然不够深入。体会到了它们之间的差异,但还不够。
  2. 这三次作业写完后,都出现了很多的BUG,导致投入大量的时间去处理解决。原因是设计思路不清晰有遗漏。所以以后需要把整个程序的思路想明白想清楚,对每个类的职能做明确的划分。
  3. 关于时间的分配和使用上,做的不好。每次都是拖到周一开始做,导致时间很紧,不得不熬夜。所以以后应该尽早开始写作业。
  4. 这三次作业尤其是第三次作业,反应了对细节问题考虑的重要性。在思考过程中考虑了最普遍的情况,却遗漏了一些特殊情况。以后,在写代码的过程中,应该考虑这部分代码可能出现的各种情况,予以分析和解决。