第一次作业：多项式计算

类图

度量

分析

    第一次作业目标是设计处理多项式加减法计算的程序。

    在这次作业中，我只写了两个类，Main类和Poly类。Main类用来输入处理，Poly类用来判断多项式指数、保存多项式、计算多项式和输出。在度量中可以看到，程序的main方法圈复杂度较高，我想这是因为main方法中的输入处理写成了面向过程模式，没有单独写输入类进行处理。

程序在计算上的实现相对简单，在输入处理的部分，存在一定的困难。如果直接使用完整正则表达式进行匹配，将会出现栈溢出错误，其原因是在运行过程中递归层数过深。后采用较短正则表达式分段匹配的方式解决该问题。

在公测和互测中，自己的java程序并没有被发现bug，所以就说一下该次作业我是如何发现别人bug的。在测试分配到的程序时，我主要是根据分支树和其程序的设计构建测试样例。首先，直接用自己根据分支树构造的自测试样例集进行测试，直接就发现了几个bug，然后对其进行分析，找出bug原因。然后，读了一下测试任务的代码，发现其输入处理部分存在一定问题，针对该问题构建样例，发现新bug。

第二次作业：傻瓜电梯

类图

度量

分析

第二次作业目标是设计傻瓜电梯的调度运行系统。在该次作业中，我写了六个类，除了要求实现的五个类之外，还写了一个Main类用于输入处理和调用请求处理，五个类中，Floor类用于模拟电梯楼层的按钮亮灯情况，Elevator类用于模拟轿厢按钮亮灯情况和电梯楼层获取，Request用于判断请求是否合法并保存请求，RequestQueue类用于保存提取出的请求变量，Scheduler类用于调度请求、并运行电梯、输出结果。在度量统计中，和上次作业一样圈复杂度较高，可能是因为类中模块化做的不够好。新出现的一个情况是某个方法的参数过多，这是因为我将请求的内容全部提取出来并存储。

在互测中，程序被发现了一个很隐蔽的bug，自己检查后发现，是自己的程序若一直没有读到第一个有效请求而输入行数达到一百行时，将会把最后一条输入作为有效请求处理。这是由自己的输入处理的循环没有写好造成的，当时为了追求美观和简洁，每一个判断条件后只写了一条语句，就造成了这个隐蔽的bug。所以不能盲目追求程序的简洁，功能的完善更为重要。

第三次作业：偶尔机智电梯

类图

度量

分析

第三次作业要求设计一个可以顺路捎带的ALS电梯，使得电梯能够在某些条件下一趟运行完成多条请求。这次作业在第二次作业的基础上只增加了一个类，即ALS_Schedule类，用于a little smart 调度策略进行电梯调度。在度量中可以看到，第二次作业的遗留问题没有得到解决，这是因为之前完全不会用这种方法检查自己的代码。而第三次作业又出现了一个新的问题，块嵌套过深，这个问题主要存在于ALS调度类中的run方法中，是因为编写程序时，将整个调度策略写在了一个run方法中，导致代码复杂度过高。

这次作业的bug还是比较多的。

首先，对于电梯的输入处理，这次的作业对错误输入的响应信息较上次作业有所不同，然而在修改程序的过程中，漏掉了request类中的错误响应信息，而在测试自己程序的过程中，很自信地没有检查错误响应部分，导致公测直接挂了十个错误输入的样例点。这个故事告诉我们，oo作业首先要保证自己的输入处理和输出格式完全正确。

二是自己的ALS_schedule类中的顺路捎带情况处理不够完善，导致某些情况下的捎带请求不会被捎带，某些同质请求没有被检测出。这对我的启示是，以后的作业尽早开始考虑，对在思考过程中考虑到的情况进行记录，以便自己在设计程序的时候按照笔记进行各种情况的处理。

总结

时至今日，也算是经历过OO洗礼的人了，智障的bug自己也写过，逻辑的bug也是写过了，在这一个月的java学习过程中，最大的感受还是应该早思考，早构思，因为自己的面向对象思想还不够成熟，所以只有花费更多时间去思考学习，才能少写出一点bug。