oo第一次总结

第一次作业：

程序度量：

类图：

评价：这是我第一个用java写的正经的工程，写的时候思路还是偏向面向过程的思路，主类之外的另外两个类里基本上都只有一个函数（对我没写错），剩下的方法基本上就是返回各种成员；main方法也写得特别长，导致project_1的圈复杂度（用于衡量代码复杂度的一个指标，由if、case、for、while产生的分支越多该指标越大）大得离谱。preprocess类和polynomial类实际上都是在做处理输入的工作：前者负责将整段字符串切成一个个多项式，后者负责将单个多项式字符串转化为数字，而多项式加减的工作则是由main方法继续进行。由于没有掌握好try-catch的操作，再加上测试不够完善，最后被测出了一个crash错误：数组越界。

第二次作业：

程序度量：

 

类图：

评价：第二次作业总算有了点面向对象的意思。程序对于输入的处理依然是通过一个方法来进行，处理完后将每一行输入转换为一个Request类。输入结束后Controller负责对电梯进行调动。由于电梯是傻瓜电梯，因此调度的策略也很简单：每次从请求队列里弹出一条请求并执行，执行完毕后对后续队列进行查重。这一次测试做得比较好，没有各种逻辑问题，但是最后还是被找出了一个bug：忘了加入忽略空格的功能……

第三次作业：

程序度量：

类图：

评价：本以为第三次作业只需要改一下电梯的调动策略所以会比较简单，然而事实却完全相反：新增的调度类的代码长度几乎和上次作业的整个工程的长度差不多……而且写的时候因为想着只需要改一下调度策略就可以了，结果一个调度方法写得无比之长，圈复杂度也达到了丧心病狂的31。这么长的一个方法导致的直接后果就是调试的时候为了改一个逻辑错误要不停地往里面添加和删除代码，结果最后就因为这个出了错：在输出的时候有几个地方格式出了错，公测挂了整整四个点（本来是可以通过构建一个private方法并传递参数来解决的，然而我直接写了8个if else）。还有一个点挂掉的原因是自己读指导书的时候理解有误，将主请求完成时刻的副请求也进行了捎带。

 

测试策略：

测试的时候我一般是先测试各种错误的输入格式，因为这种问题最好测，即使整个工程没有完成也可以测出结果。而后在工程完成后用各种短数据进行测试，和公测相似，每次只测试一两个错误树的叶节点。

这几次测试其他人的代码时其实比较尴尬：第一次对方拼错了"ERROR"，结果公测半颗测试树都没过，能挂的点都被公测找出来了（可怕的是即使ta的代码把单词拼对了也还是会挂掉四分之一的点）；而第三次的代码则质量十分低下，随手一测就找出了一堆bug。而且很烦人的是这两个人都把所有类放在一个文件里面，让人完全不想读。

 

总结：

1、不论什么情况，程序都不能crash：只要把整个main方法放在一个try里面就可以解决。（当然测试还是要做好，否则出一堆error也不好看）

2、尽量把一个长方法拆分成几个独立的方法，否则很可能产生改了一处忘了另一处的问题。

3、写代码的时候要一个类放在一个文件里面。

4、测试的时候要考虑到所有的情况，即使是两种情况十分相似，只要二者不一样就要用不同的样例来测试。