OO前三次作业总结
一、程序分析
1. 第一次作业
以下是第一次作业的OO度量信息
由于第一次比较简单，所以其他指标相对正常，但是还是出现了isLegalChar方法循环复杂度过高的状况，当然这是由于检查非法字符造成的，所以出现了很多分支，故暂且忽略不计。而且一共只有两个类，类与类之间的协作也很简单，故省略类图。
2.第二次作业
以下是第二次作业的OO度量信息
第二次作业类图如下
在第二次作业中各种指标相对来说都在正常范围以下，类的设计与协作还算合理。在这次作业中能深刻体会到面向对象的优势，注意力更多的在每个对象本身的属性与方法，然后就是对象与对象之间的协作，更符合生活中人们的思维。这次的缺点很明显，在编码习惯上暴露上了较多问题，比如混搭了变量命名方法（从类图就可以看出来），不写注释等问题。这些问题在下一次作业中有所改观。
3. 第三次作业
以下是第三次作业OO度量信息
第三次作业类图如下
相对来说，第三次作业要处理的逻辑比上次复杂，所以我更改了实现的思路，让电梯一层一层爬，再不断扫描队列，用Scheduler处理调度逻辑。但是由于要求的细化，使得实现的代码变得非常冗长，虽说在写完后进行了一定程度的重构，但是还是避免不了度量图中说的处理调度逻辑的函数dealMove函数块嵌套深度过大的问题。虽然bug少，但是总让人感觉Scheduler中的逻辑还是太过于面向过程，这是本次最大的缺点。
二、自己程序的bug
在这三次作业中，第一次集中了最多的bug，很惭愧，第一次的bug一个来自于我没认真读指导书，一个来自于一个很致命的我自己的问题，那就是打印结果时候在最小次数的结果为0时会多打印一个逗号。这种简单的问题在我测试时没有覆盖到，是我自己不认真的问题。除以上bug外，还有一个爆正则的问题，虽然代码已经采取了分层处理的方法，但是却忽略了单个数字过大的问题，因而被找到了bug。这个bug也给了我一个启示，一定要预防各种情况的出现，因为不知道测试者会用何种困难的用例来测试你的程序，所以在编写时就要格外注意细节。
第二次和第三次作业在编写代码时就格外注意了代码的灵活性，以应对需求的变化，而且万一个人有什么错误理解保证能方便的修改代码不至于全部重写。而且在编写代码时就设计了各种模糊情况的测试用例，准备较为周全，所以暂时没有被别人测出bug。
三、分析别人的bug
主要使用的都是自己在编写代码过程中，针对好多模糊的位置设置的测试用例。对于别人的代码，当然会看代码的可读性是否优秀，如果不优秀或没有注释，很难理解对方的处理逻辑，就只能从一些边缘的数据预处理入手来设计测试用例（这种方法在第二次作业中生效了）。而对于可读性比较优秀的代码，会简略看对方处理逻辑是否有漏洞。（然而一般可读性比较优秀的代码只要理解没有大问题，逻辑也不会有问题。）
四、心得体会
我最大的感受，就是设计对于每一次作业的重要性。一个好的设计能大大降低编码的复杂度，还能降低出现错误的概率。比如第二次作业，我是在电梯类中直接计算了到终点的时间，这样设计对于第二次作业很友好但在第三次作业中就很难处理捎带逻辑，因为某些捎带的指令会导致之前本不能捎带的指令变得可以捎带，所以我就将处理过程改变为电梯一层一层向上，再用调度器处理捎带逻辑。脑中形成了这种设计思想以后，再写代码就比较容易了。所以再今后的作业中，一定要先设计，而且在设计的同时，就要考虑到代码实现是否方便，灵活性是否优秀等问题。
