OO

 一.分析

第一次作业:

第二次作业：

第三次作业:

分析：

 　　第一次作业全复杂度在check极高，本来第一次要用正则表达式。因为拖延症导致只能使用最简单的if else去判断表达式是否合法o.o，从第二次开始使用正则表达式，圈复杂度下降，为了区分各种错误写了一些各种if else语句，但比之前更加简洁，虽然第一次判断没出错，但正则确实很好用QAQ。

二 分析自己程序BUG

1.bug分析

　　数据超出边界。第一次作业对于自己程序的边界没有仔细的测试，导致在写程序时漏写了=号，导致边界出现错误。第三次对于同层请求的判断失误导致遗漏捎带。

2.程序结构问题

　　每次作业对程序的设计没有深入的分析，导致对后续的debug造成麻烦。

　　第一次作业我将多项式按照次数将其分割，但类的实现比较臃肿，在读取多项式时同时对多项式进行加减法，程序只能针对单一的功能，如果进行多项式的乘法，则无法继承已有代码。

　　第二次作业作业规定了所实现的类，但每个类实现的东西有多有少，没有合理均衡的设计类的属性，方法。导致对第三次作业造成影响，只能修改原有代码，能够实现新的功能，继承原有的属性和方法。

3.如何发现别人程序的bug

　　如果简单测试别人的程序要有合适的测试集。如何构造好的测试集是一个测试者应该有的能力，问题不能是一个一个的找，将问题分为不同的分支，根据不同分支延伸下的分支，不断扩展，全面覆盖程序的所有问题。

　　测试集测试的程序测的bug一部分是普遍性问题，一部分是特殊性。普遍性问题通过测试集就能发现，但特殊bug隐藏在程序内。代码一般会有自己的条理，如果所测试的部分代码混乱不堪，有各种乱七八糟的变量，对于变量有莫名其妙的使用一般都会隐藏问题。对于程序员，他们对于自己程序bug的修改都是针对性的，很少有人会重写程序，从而导致新实现的功能会和原有的功能冲突，新的bug的解决也可能导致原有bug的复现。所以学会阅读他人的程序是有必要的。

三.体会

　　准备的越充分，代码覆盖的问题会更广，最后在测试阶段会节约很多时间。一个好的程序在设计前必定会有一个详细的构造方案，没有一个工程是在脑子中完成的，好记性不如烂笔头，这样会减少遗漏的问题。当然有了设计档案，你也可以在设计初期寻求大佬的指导了，当然不能依靠他人，但是能从设计就解决遇到的问题会减少debug的痛苦。如果你把自己丑陋的代码发给大佬寻求帮助，估计很难找到，甚至会被大佬嫌弃。大家都经历过计组的洗礼，如果没有设计文档，直接去设计CPU，估计你都不清楚有些接口有啥用。有付出肯定有汇报，程序重在设计，代码只是对语言的熟悉而已。

　　面向程序的设计风格已经深入影响到我们，喜欢一股脑的写完程序，该做的事情不做，却实现了其他类的功能，牛头不对马嘴，对于类的定性不太清晰，不同类之间界限模糊不清，通过阅读他人的程序，发现自己的代码可以分解成不同的部分。希望通过接下来的实验让我继续了解面向对象，也希望自己的程序能给他人带来帮助。