面向对象第四次作业
面向对象第四次作业
代码分析
第一次作业
UML图
代码复杂度分析
对于我而言，这次作业的难点主要是以下几个方面：
- 由于之前已经学习过面向对象的先导课，对
java的一些基本语法和面向对象的思想有了初步的了解和认识，但是因为已经很长时间没有敲过java的代码，因此难免会显得生疏，虽然代码也使用了多个类和方法，但是各个方法之间的分工不明确，此外main方法承担了大量的工作，因此main方法的复杂度较高也就是必然的了- - - 在处理输入的多项式的时候我使用了正则表达式，由于之前没有学习过正则表达式，因此在正式开始工作之前先耗费了一定时间学习正则表达式的使用。另外，由于我每次都是提取出最前面一个多项式进行处理， 在很大程度上避免了爆栈情况的发生。
- 在面向对象先导课时，老师推荐使用的是Eclipse，而从本次作业开始，我换用了IDEA，在IDEA的使用和GIT的配置方面付出了一定的学习成本
- 作业指导书叙述的不明确和频繁的需求更改，让我回想起了被先导课支配的恐惧
本次作业中出现一个bug，作业指导书中说不会出现系数相同的情况和假如输入不满足输入规范，可以自定义处理办法，并在说明文档中写明，我的理解是对于这种情况的处理可以在readme中自定义，但是在公测集中对于这种情况的处理是报错。
第二次作业
UML图
代码复杂度分析
经过了第一次作业的折磨，到了第二次作业已经开始逐步的熟悉面向对象的一些编程思路了。
这次作业除去囿于作业指导书要求不得不加上但是没有被利用上的类以外，包括以下几个类：
Requests 请求
获取输入，判断指令是否有效，并将输入的有效指令转换成RequestsQueue接受的数据类型
RequesQueue 请求队列
管理请求的队列
Dispatcher 调度器
用于管理电梯的运行状况，控制时间本次作业中已经开始逐步分离各个方法的功能，另外也逐步熟悉了自己所使用的IDE和在先导课上养成的一些编码习惯，在敲代码的时候较为得心应手，但是在前期的算法设计方面，一方面由于作业本身的难度，另一方面由于作业指导书人为增加的难度，在算法设计以及输入输出的格式方面走了许多的弯路和来回修改，令人十分不悦。
本次作业我使用循环扫描的方法处理同质请求等，因此Dispatcher的run方法由于涉及到读入一个请求后扫描其后的请求，需要循环，因此复杂度较高。request类的judger方法用于判断输入格式，由于if-else的数量较多，因此复杂度也较高。不过，虽然当时没有代码复杂度的分析，在第三次作业正式开始编码之前，我先修改、精简了第二次作业的算法，在第三次作业中的代码复杂度分析中可以看出。
本次作业出现了两个bug，但是错误处是同一个，错误的原因是因我自己傻了。
String REGEX= "(\\(FR,\\+?\\d{1,2},(UP|DOWN),\\+?\\d{1,10}\\))|(\\(ER,\\+?\\d{1,2},\\+?\\d{1,10}\\))";
Pattern P = Pattern.compile(REGEX);
Matcher M = P.matcher(str);
if (!M.lookingAt())
{
print("不符合语法规则");
return false;
}在debug的过程中，先是尝试de出一个后来发现是我正则表达式的错误的问题我将lookingAt方法改成了matches，在修改正确正则表达式然后经过了一些测试输入之后，没有问题，我又将matches改了回去……改回去的后果就是，在一个符合格式的输入后跟着无数无效的内容不会报错，比如(ER,1,0))这样公测集中说多余右括号和(ER,1,0)dsnjfanofnacoamo这样的内容，共计被报了两个bug。
第三次作业
UML图
代码复杂度分析
这次作业在第二次的基础上增加了捎带的内容，新加的scheduler类在继承dispatcher类的基础上，重写了有关捎带的内容。这一部分我采用的是递归和循环扫描的方法，此外由于对于指令的分类情况较多，最多出现了四五层的if嵌套，因此有关指令扫描的identifier和schedule方法的复杂度较高。由于修改了第二次作业中的dispatcher类，进行了更为明确的分工和简化，其复杂度有所下降。
这次作业的bug一方面是忽略了与第二次作业不同的输入要求，对于第一条指令不是(FR,1,UP,0)的情况没有完全处理；此外，由于更改了一小部分第二次作业的逻辑，没有完全考虑到所有情况，出现遗漏，没有输入有效指令这一情况下没有正确处理，输出了不必要的内容；最后，在算法方面，虽然在自测中使用别人的样例发现了bug，但是由于此bug的复现率低、样例的复杂，没有定位到bug，在自测了大量其他指令中也没有出现问题，就直接带bug提交，最后通过了所有公测点但是被互测找出了bug，这里要感谢测我bug的同学，因为他成功定位了我的bug……如果他没有发现我的bug，虽然不会扣分，但是下一次多线程心里也会没底= =
寻找bug的策略
在寻找自己的bug的时候更多的靠的是编码前的设计和编码时的思考，还有在结束编码后的自行构造有针对性的测试。
在寻找别人的bug时，我最先是利用自己的测试集进行测试，先大致的找到对方一些可能出现的bug，包括基础的功能、一些复杂情况下的测试、边缘测试还有作业指导书不断修改过程中前后并不完全一致的以及不明确的要求。
在之后就只能靠阅读对方的代码，在阅读的过程中怀疑他写的一切内容，思考他为什么这么做，这个是干什么的，这么做会不会有问题。然后记录下所有可能出现的问题然后针对性地构造样例。
心得体会
在正式开始编码之前充分设计、验证算法
在开始编码之前首先在草稿纸上构造好合理的样例，画好处理的流程图，分析各个类和方法之间的联系，在这一步的过程中往往能够因为不需要思考详细的代码实现而关注算法本身从而找到设计中的bug并加以完善。
在完成这一部分的思考后，在实现的过程中可以完全按照自己纸上的内容逐步实现，减少bug和遗漏。
编码的过程中测试
在完成一个独立的功能单元后就对齐功能加以简单测试，以免在综合测试的时候因为难以定位而将单个功能单元的简单bug复杂化。
修改代码时考虑修改的影响
在这几次完成作业的过程中，都出现因为修改代码却没有考虑完全而导致的bug，在修改代码的过程中只专注于特定问题的解决而忽略了对于其他部分，尤其是已经测试过的情况的影响。
优质内容筛选与推荐>>1、datagrid数据导出到excel文件给客户端下载的几种方法
2、ExportGeo
3、swaks制作钓鱼邮件
4、0x21 剪枝
5、ZABBIX