第四次作业

 第四次作业

一、基于度量来分析自己的程序结构
（1）多项式计算器
• 度量类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代
码规模

• 计算经典的OO度量，分析类的内聚和相互间的耦合情况

　　可以看出主函数比较复杂，因为懒得传参数写成方法，所以计算都写到主函数了。

•自我点评优点和缺点

　　正则拆分过程可能有些冗余，但整体来说比较满意

（2）傻瓜单线程电梯
• 度量类的属性个数、方法个数、每个方法规模、每个方法的控制分支数目、类总代
码规模

表示方式“n，m”，第一个为行数；第二个为分支数，省略则默认为0.

• 计算经典的OO度量，分析类的内聚和相互间的耦合情况

 　可见在检查输入格式并实例化的过程中嵌套层数过多，reader的内聚较低。

•并自我点评优点和缺点

　　拆分地还是很满意的，虽然第三次没有用上，可能是拆分地方向与第三次作业不一致

　　算法思路比较清晰

（3）智能单线程电梯

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

• 计算经典的OO度量，分析类的内聚和相互间的耦合情况

 　　同样，检查语法中嵌套了ans和list的实例化，内聚低。

• 并自我点评优点和缺点

　　整体思路比较明确，写完之后基本没调bug

　　重写太多，而且集中在了一个类里面

 

二、分析自己程序的bug
　　• 分析未通过的公测用例和被互测发现的bug：特征、问题所在的类和方法
　　第一次、第三次作业暂无bug
　　第二次作业bug为在匹配ER命令时，正则表达式没更新，使得楼层位数过多导致超过int范围而crash
　　• 关联分析bug位置与设计结构之间的相关性
　　第二次作业中，两种命令是分开匹配的，因为这样写在分割字符串并实例化请求类时方便一点。在实现的过程中，就直接把FR的代码复制给ER了。这样做的坏处就是每次改动将会异常麻烦，还会容易遗漏，就像这次的bug。其实完全可以把检查和分裂字符串写在一起，只不过需要分开赋值楼层和时间就可以了，FR再单查一遍两边边界分别不能UP和DOWN就可以了。

　　• 从分类树角度分析程序在设计上的问题

　　这三次作业在正确性方面设计上都没有什么大问题。

　　（1）分类树：

 

　　第一次作业比较简单，主要是熟悉正则表达式的使用。
　　输入格式检查：我个人觉得第一次分类树在非法输入上比较针对写状态机的同学，我使用的是正则就不一一分析了。。。正则这次唯一要注意的是，matches在线索字符串过长的时候会爆栈（原因待分析），所以要分开匹配。
输入内容检查：在程序中，实例化每个项之前都会进行，这项没有问题。
　　功能上：关于压力测试，实际上在设计程序的时候其实并没有考虑节省空间的问题，只是在实现的时候尽量避开了内存泄漏，减少了字符串直接加的情况。还需优化内存的使用。
　　（2）分类树：

 

　　有了第一次作业的经验，这次的格式审查没花费多少时间，使用reader类直接把格式测试和数字范围搞定。正常功能非常简单，不做赘述。关于同质请求的实现，首先是要理解好同质请求“这条没执行完时又来了一样的”以及不算开关门这两点猴就很好实现了，直接向后暴力扫描就行。这里的扫描范围可以进一步优化，如以时间为限制。写的时候图省事就把整个队列遍历了。
　　（3）分类树：

　　　　这次的难点反而是正常功能的测试。关于捎带其实编程时也是对边界不是很明确，脑子里面没有概念，基本都是按指导书一步步来的。关于捎带的分类，自己和分类树测试地差不多。同质请求定义没变，只不过需要增加判断的次数。

三、分析自己发现别人程序bug所采用的策略
　　• 列出自己所采取的测试策略及有效性，并特别指出是否结合被测程序的代码设计结构
来设计测试用例

　　虽然没发现过bug，但是仍然有了一些经验。

　　最重要的一点就是一定要先看readme，然后问清楚助教是不是在readme范围中。这样可以最大程度上避免误报。

　　我的互测步骤一般为：readme-》跑本地自己构造好的特殊样例-》跑随机-》看代码思路，找逻辑和笔误

　　看代码是最痛苦的，因为没有什么注释（有一个还是乱码）而且量还很大，所以要从main函数入手，利用单步调试了解思路。

　　我的看代码步骤：readme-》大概看一下类，从名字能基本看出来是干什么的-》看输入部分（最容易看懂的部分）-》从main进入单步调试-》单个函数理解

　　容易被公测遗漏的笔误有：等于号、每次使用是否初始化、变量类型不统一（如int和long），if和for有嵌套漏洞（括号太多放错地方）等。

　　我抽到的代码，由于过了公测和我自己的全部样例，基本上思路都没问题，只可能有一些忽略的笔误情况。

四、心得体会
　　• 关于设计问题、 bug等方面的心得体会

　　教训：代码要先想好，将全部都规划好再写

　　写程序基本步骤：看指导书-》结合例子，进一步明确要求-》分析边界-》思考特殊情况-》出算法-》用例子检验-》优化算法-》拆分类-》动手编程-》调试和测试

　　测试一定要按照自己写的思路测试，不能“选一个代表”进行测量，如上次错误就是，选择了FR做边界测试，结果ER炸了

　　测试基本步骤：测量非法输入（形式上）-》非法输入（内容上）-》基本功能-》特殊功能-》边界-》压力-》组合测试-》大量的随机代码
　　• 如何评价

　　总的来说，三次作业都顺利写下来了，不过关于算法的简单和类划分的层次方面还不是很满意。因为时间比较赶，总是想到一个算法就写了，没什么想第二种方法并比较的时间（比如电梯队列的处理，是模拟还是直接计算）。

　　写JAVA程序时还是有些知其然而不知其所以然，尤其是存储机制。引用对象指针和对象想的还不是很清楚就写了。比如将同一个实例加入一个队列，还希望是原来的那个对象而不是新建的。所以声明指针（用于加队列）的时候不能new，直接挂在那里就可以了。

　　对JAVA的内置类和方法还不是很了解，感觉有些代码可以借助内置方法实现。

五、建议
对同学：
　　看到第三次还是有同学跟我犯一样的无效错误，十分难过，再此呼吁大家使用txt，很多情况下本地看不到pdf的个人信息，换个机器或者阅读器就能看到了。。。
对课设：
　（1）希望能调整一下答疑和通知体系
　　具体内容：将微信班群改为同学自己讨论的地方，需要助教出面答疑的用讨论区，同时关于对作业打的后续补丁性质更新、readme自定义范畴和后续的查bug环节的答疑也希望发在讨论区（可以开多个模块，如果方便的话），可以在通知版提醒一下大家。
　　原因如下：
　　1.班群信息过于繁琐，翻阅不便，且容易遗漏。
　　2.有些班群中的提问与讨论区重复。
　　3.助教发现回答疏漏时不方便更改。
　　4.各班群答疑内容不平均，使各班信息不对等，使得申诉变得麻烦。
　　我认为这样大家都会方便一点，希望老师能考虑一下我的建议。
　（2）希望在通知板的通知措辞能尽量简洁、严肃一些。