第一次作业
类图与度量分析结果
BUG
自己的程序公测与互测都没有bug。
测同学的bug时，通过阅读readme发现他有个地方和助教答疑时给出的规定冲突，给弄了个bug。
小结
第一次作业的内容是实现一个简单的多项式计算器，重点在于输入处理，也没什么好说的。由于忌惮正则表达式的爆栈问题，就没用正则，自己手写的check。作业完成过程就是周二晚上看完指导书写完c复制粘贴到java中再把该改的改了一波流搞定，可以说是素质极差了，也正因为如此第一次作业就完全是一个面向过程的程序，从上面的度量分析中也可以看出我的圈复杂度时比较大的。
第二次作业
类图与度量分析结果
其中类图里还有三个枚举类型不知道为什么贴不上
BUG
自己的程序公测互测均无bug。
我测试的同学写得很好，跑了一些数据并阅读代码也没发现什么问题。
小结
第二次作业内容是实现一个傻瓜式电梯，重点在于对指导书的理解。这一次作业我写的程序稍微有点面向对象的样子了，然而还是由于忌惮正则表达式的爆栈问题，我沿用了一部分上一次作业的输入处理，导致McCabe Cyclomatic Complexity这一项跟上一次作业是一样的，以及其他的地方还是有些面向过程。然后在这次作业过程中，我花了很多时间读指导书+读issue+读客服群里的聊天记录，完全确认所有细节后才开始动的手，然后还不想熬夜，所以这就导致我不得不周三金工课上边焊板子边写代码，焊完板子回宿舍生死时速，不过好在6点半左右都搞定了，也就没有翻车。
第三次作业
类图与度量分析结果
BUG
我自己的程序公测无bug，互测由于我第二到第三次作业，允许的+号从一个变成了两个，然后这个check因为发烧意识模糊忘记改了，被细心的测我的同学发现了。
我测的人程序比较奇怪，只有3个类，很好奇他是怎么过的上次作业，然后自然也就没有写规定的继承和接口，报了incomplete，然后测各种数据都没错，细读代码也没发现问题。
小结
第三次作业内容是实现一个有捎带功能的电梯，重点依然是对指导书的理解。从上次到这次由于我的调度器扩展性不是很强，因此基本上是完全重写了。在重写的调度方法里，有很多重复的代码段，大量的代码也是顺序执行下来的，所以在面向对象性这一方面这次作业我是没多大进步的。然后的话这次作业的过程更加惊险刺激，之前同样是花了很多时间研究指导书+issue+聊天记录，时间更加紧迫，关键的捎带部分甚至是周三中午才写的，然而下午我就发烧了，一边烧一边debug，也同样回宿舍生死时速，不过得益于我残存的意识和造数据、debug能力以及同学的帮助，我还是在6点50左右成功交上作业，但是这个过程回想起来还是有些后怕的。
心得体会
1.花时间弄清楚指导书和各类信息是非常重要的，头脑不清晰地去写代码只会事倍功半，到处打补丁非常浪费时间。我之所以能在较短时间内写完作业完全就是因为我弄清楚了自己要写什么。
2.关于debug，我采用的debug方式是输出调试+大力眼查，因为这两种方式相对而言效率较高，而且在逻辑上有连贯性，当你能够仔细分析好一段代码执行前需要什么，执行中发生什么，执行完有什么后效以及这些实际长什么样，再结合对指导书的把握，是不太容易出现查了个bug出来其他bug的情况的。
3.关于查bug，首先看readme，说不定会有惊喜，我第一次作业查出的bug就是这么来的，然后就是用借来自造的数据覆盖性测试+通读代码去发现问题。
TODO
1.克服拖延症。每次我开始写代码时可能大部分同学都已经写完了，虽然说我花了很多时间去读指导书，最后也确实弄懂并且为之后的生死时速打下了坚实的基础，但实际上自己也清楚在思考指导书时，很多时间任由自己的思路处于停滞状态，不想去推进，遇到问题只想等着更清晰明确的信息出现，这是不对的，总处于不确定因素中是不好的习惯，一定要改。
2.学习代码规范改进代码习惯。这几次作业我的代码大体框架上是面向对象的，里面的内容是面向过程的，这主要因为时间紧迫再加上写代码时不想破坏思维的连贯性，因此很多东西就一路写下来了，也就没有管规不规范，所以以后在克服拖延症的前提下，应该着重注意自己的代码是否符合规范。
最后，我想以一个gif图结束本文
