OO第一、二、三次作业总结

 一、作业分析

 

第一次作业

 

作业简介：编写程序处理规定模式的多个多项式表达式输出运算结果

处理方法：使用正则表达式从输入中提取出符合规则的单个表达式，构造表达式对象按照次数对各项进行排列，存入数组，最后从头遍历数组依据多项式符号决定运算方法，运算结果依次与下一个多项式进行运算直至数组为空

Metrics度量结果：

类图：

自我评价：

优点：思路上可能相对清晰，数据结构比较简单易于理解

缺点：本次作业对于面向对象的编程思想了解得不够深入，可能程序的编写上有一点面向对象的味道但是总体实现上可能还是面向过程的思想，这一点在度量结果中也有体现：一个类承担了太多的职能、代码臃肿、封装做的不够完善。

bug分析与反思：

本次作业的公测和互测虽然并未被发现bug，但是在自测debug的过程中自己却清醒地意识到这样的编程风格有很多隐患，局部代码臃肿、职责集中等很容易导致出bug却很难去寻找，降低了代码的可读性与可维护性

 

第二次作业

 

作业简介：编写程序模拟FAFS调度模式电梯的运行，执行输入的请求并输出执行结果

处理方法：读取输入过滤非法内容将合法请求存入队列，读取步骤结束后调度器从执行调度方法从队列挑选出要执行的请求进行执行并对挑选途中遇到的同质请求予以输出报错，循环此过程直至队列为空。

Metrics度量结果：

 

 类图：

自我评价：

优点：对于同质请求的判断引入了“灯”的概念，灯是全局的，整个程序的灯有三个实例分别是楼层UP灯、楼层DOWN灯、电梯灯，这三个灯对象分别有两个长度为10的数组用于记录相应灯的“发光”时间段，所谓同质指令无非就是在一个灯亮着的时候又去按了它，所以每当有一个请求被执行就按照请求的信息更新相应的灯的“发光”时间段，判断同质时也很简单只要这个请求发出时刻处于“发光”时间区间内那么本条指令就是同质的（但是这种做法无法反馈现在的指令是与之前的那一条指令同质）。

缺点：由于灯的存在导致调度模块的调度方法if-else嵌套较深，这一点在Metrics的度量结果中有所体现，对于面向对象的编程思想的学习理解有所深入但还是无法熟练掌握，代码耦合情况还是有很多，这与自己构思不够成熟就直接动手写代码有直接关系。

bug分析与反思：

本次作业的公测并无bug，沾沾自喜的时候突然看到作业被申请了无效也是懵逼，原来没有删除干净的个人信息被热心同学发现了，所以互测部分就不提了，自测时除了笔误导致的bug外逻辑部分并无问题，局部代码臃肿职能集中的问题虽然有所减轻但依然存在这仍是给debug留下的坑

 

第三次作业

 

作业简介：在第二次作业的基础上引入捎带策略（ALS），其他格式等要求基本相同

处理方法：每次选取一个主请求计算出一个预期的到达时间更新灯的时间属性然后从头遍历队列选出最优的可捎带请求（所谓最优是指离电梯当前所在楼层最近的可捎带请求）对遍历途中遇到的同质请求进行提示输出，执行最优捎带请求，更新相关属性，再寻找最优可捎带，直至没有可捎带请求的存在最后执行主请求，这里值得注意的是，寻找可捎带请求的遍历过程的结束条件是遇到一条请求它的发出时间大于等于预期到达时间或者到了队列末尾，循环此过程直至队列为空

Metrics度量结果：

类图：

自我评价：

优点：对于对象化的程序设计思想有进一步的认识与实践，算法较易于理解

缺点：延续前一次灯的设计使得有些步骤的操作过于笨重数据结构较为复杂，代码可读性很低，由于对主请求目的楼层存在可捎带请求的所有情况没有考虑周到导致最终临提交的时候新加了很多代码，这些码显得比较突兀逻辑也不是很清晰导致这次作业的bug全部与之相关

bug分析与反思：

公测挂掉了一个很奇怪的样例，最后单步调试的时候才发现是因为自己某个函数使用的是全局的flag，没有每次进入函数时先把flag置false导致了这个问题的出现，由此也给自己提了个醒，flag这种能够影响程序走向的变量使用的时候一定多加小心，要一遍遍地逻辑上进行推演而且最好不要用全局变量。互测阶段被发现了两个bug，第一个与前面所说flag相关，第二个是在面对主请求目标楼层存在可捎带请求的时候，程序未按照请求发出时间输出请求运行信息，由于之前未考虑到同层可以存在三个可同时运行请求的情况，导致了此bug的出现。由此也提醒了自己，以后再进行编程时不能脑子里有了大概的思路就开始动手写代码，一定要明确所有需求所有功能之后再进行编程实现，而且编程过程中要反复核查代码逻辑的正确性。

 

二、互测时bug寻找策略

 

互测时首先要读懂别人的代码要明白每一步的实现，如果代码实在复杂也要至少明白大体的实现过程。寻找bug主要有两个方向：一个是寻找逻辑类错误，这种错误通读代码时容易发现。另一种是寻找格式之类的“硬性要求”没有实现导致的bug，主要是从分支树进行核查，或者程序运行结果与readme有出入，比如正则表达式书写与readme描述可接受的输入不符。最后要做的就是测试边界数据、大数据和随机轰炸。

 

 

三、心得与体会

 

学习方面：

（1）动手写代码之前一定要明确所有的需求所有的功能，最好能有流程图一类的东西，而不是稍微有一点想法就去实践，这样可能导致边写边发现bug改正之后又增加了新的bug，效率与正确率往往不如一开始仔细研究需求明晰程序的结构再去实践的同学（别问我怎么知道的）

（2）有不懂得多去CSDN、cnblog等博客去查找相关的资料，很多知识往往是顺带学会的，查这个知识点的时候就顺带把相关的知识也学会了（到目前为止一半多的零碎知识都是从网上一点点查的）

（3）设计类的时候最好明确各个类的分工职责，尽力避免头重脚轻局部臃肿（对debug有很大帮助），应该明确各类分工，而不是披着面向对象的外衣，实质确是面向过程的实现思想。

（4）对待自己的程序要像测试别人程序时一样严格，尽全力去发现每一个bug

其他方面

（1）除去知识层面的学习，OO课程让我进入到了更具有“现实”氛围的学习环境，每个人都面临着测试者，编写程序时所考虑的也不仅仅是能处理正确的输入，我们更像是在开发软件而不是做简单的代码练习，这些为将来的工作环境做了很好的铺垫。

（2）团队的力量无穷无尽。一个人可以想到的情况可能有限，但是一群人聚集在一起讨论一个问题所考虑到的情况覆盖面就很广，在这几次作业中每当遇到瓶颈了去与同学讨论一番往往就能获得解决问题的方法或者听一听别人讨论的问题自己有的时候也能发现自身的不足去改进自己的代码还有就是互测数据的分享，在这里对给予过我帮助的同学、朋友们表示衷心的感谢。

（3）永远不要认输。第二次作业因为个人信息的问题被判无效，当时心态一度处于爆炸状态甚至影响到了做第三次作业的状态，但是事后自己想一想，这也算是给自己上了一课，除了提醒自己做事要万分谨慎，也算是锻炼了自己的心理素质，可能以后的工作环境就是如此，没有人去怜悯你同情你，除了变得更加强大你别无选择。

（4）年轻人还是少熬夜.....