我系的重课真的是懒癌克星。
一如计组当初的警语：惰怠会导致惨剧。从寒假就抱着一本JAVA从入门到精通回家享乐了...
第一次作业：多项式加减
类图 & 度量
第一次作业相对简单，所需的类不多，逻辑上相对容易实现，重点在于正则表达式的学习使用，但是一夜速成JAVA还是正则表达式爆栈了
，虽然在提交之前有测试到这个问题，但已经来不及更改，其他没有错误。
从度量分析可以看到，因为没有将main()方法独立成一个类，并且在main()中实例化了其他类，导致快嵌套层数比较高，在小规模的工程中尚可，
但代码规模一大，即便是在后面作业的三五百行的代码量，都会因为过深的嵌套，而使得代码难以读懂和修改。
第二次作业：傻瓜调度电梯
类图 & 度量
第二次作业需要实现电梯的傻瓜调度，实现上也不难，这次作业吸取教训提前一天写，但你永远不知道你的debug需要多长时间！！，这次作业虽然
公测全过，但是仍然被查到一个点，原因是判断同质指令的条件存在考虑不周的状况，这本该在自己测试代码的阶段查出，然而当时只测试了一些短
的样例，以及临界大样例，不足以充分测试代码。还有就是对于异常触发机制的使用并不了解，这次作业中主要基本考虑了所有的情况，而没有很好
地尝试使用try-crash机制。
从度量上看，还是存在多层嵌套的问题 ，这个问题其实现在才意识到，设计上参考了课程PPT，但实际上还是按照自己的思路
在写，在对象的抽象能力上，有待加强，实际上第一、二次编程的思想还是更偏向面向过程。
第三次作业：（A Little Smart）ALS 调度电梯
类图 & 度量
第三次作业的类图要复杂得多，需要满足继承、多态、接口等编程范式，难点在于ALS电梯判定捎带条件，此时我在代码测试上的不足
就体现出来了。这次作业代码规模要大得多，前期对需求文档的阅读理解不足、构思的不全面，都导致编程阶段bug的泛滥，不断测试
短样例，不断打补丁，添加限定条件，导致代码可读性极差，给debug造成一定困难（自己都不想看自己的代码），前期的准备很是不
足。然而最大的错误，却是一个低级错误，由于输出的方法从第二次作业的基础上修改，一些没有预料到的参数，在特定的情况下会被
输出，这让之前的努力白白浪费掉，极其可惜。可见，虽然编程实现上，可以磕磕绊绊把功能实现，但远没有能够完成一个完善的工程，
编程的习惯才是这些问题发生的根源。对于oo这种比较大规模的编程题，如果所有事情推得太后，往往没有给自己留下后路，也没法有
充分的时间测试优化自己的代码，最终提交的版本始终不是自己最满意的。
代码度量上看，嵌套问题还在，其他的复杂度之类的尚可。不过再审查别人的代码过程中，发现他人代码的风格极好，尤其是之前第二次作业
抽象模块封装都要高我不止一个层级，明显优化过多次，赏心悦目。
自己程序中的bug
有：条件判定不涵盖所有情况的bug、爆栈的bug、输出错误的bug
主要导致bug的原因是，没有安排合理的编程时间以及粗心大意，还有就是测试驱动开发的能力不足，实际上多数错误不是编程能力上的不足
，而是编程习惯确实有待改进。包括与别人对拍的过程中，也觉得自己由于时间比较紧张，没有非常仔细寻找bug，而是追求速度。希望下次
真正将心态转换成真正在编写一个工程，而不是在赶作业。
别人程序中的bug
前两次作业中的程序没有找到bug，第三次程序存在同质电梯请求判定错误的bug，而且README基本没写，发现别人在细节的处理上更加干净
利落，类的划分更加恰当，即便会有bug，但代码风格更好，也更加容易找到bug。我想这是代码量上的差距，需要用时间来弥补。测试别人代
码主要还是对照错误分支树构造短测试样例来测试，同时阅读代码找bug，但是效率不高，这种方式容易让人厌烦，应当尝试编写脚本自动测试。
心得体会
面向对象编程的思想需要大量代码的实践来体会，就目前的感受来看，面向对象编程的思想在多对象交互的情景下非常实用，比面向过程更加容
易理清思路，而在未来的开发中面临的多数情况基本是多用户群高并发的场景。看到大佬们对作业的热情和投入，觉得自己在这门课上的付出似
乎并不足够，所以下次也要加油鸭
。
2018-04-02