大一时听学长学姐说计组、OO，心里还是蛮怕的。因为数据结构GG了，所以对于写程序提交测评的课都感觉很虚。计组做下来感觉还好，头发还在（也就通宵了一次熬了几次夜）。OO刚开始的时候遇到了很多问题，有请他们出列：
·不会java:从没有接触过java，也没有去上前导课，所以还要边看教程边想程序怎么写，想到的方法需要怎样转化成java的实现。（梦拓早建议我们学学java，然而玩过去了）
·面向过程的java程序：由于写C写的比较多，面向过程的编程在我脑海里已然根深蒂固。虽然读过一点微小的C#，但看懂是一回事，自己写又是一回事。于是第一次作业我直接把C程序的函数变成java的方法。。
第一次作业
类图
分析：可以看出Term类与主类是聚合关系。Compute中有Term组成的数组，数组解散了Term还在。
由于第一次作业写得不好，故没有度量。
我的Bug（我的虫）
看完第一次的指导书时，我还是不太知道自己该怎么实现。去学了点正则，但是感觉自己很难解决输入之后的问题，于是用了状态机来写。程序只对一个数组操作。第一次作业还要写C程序，所以我先在C上写了一遍，然后再翻译到java上。
我公测错了一个，是最后输出的时候我的逗号输出判断错误：在数组第一个系数不为0的项指数为0时，将多输出一个“，”号。还是蛮蠢的错误2333数学学得不好。
互测没有被报Bug（状态机太难出错了）
同学的Bug
拿到了一位julao的作业，观摩学习了他的代码。同样是状态机，他写得比我简练很多。早早的放弃互测233
总结
这一次作业基本熟悉了java语法（输入输出语句），发现ArrayList真滴很好用，也知道如何根据错误分支树给自己Debug。学习了正则表达式，在后面的作业中也用上了。
第二次作业
类图
（胡乱）分析：有三个类依赖Request类：Floor类会生成它的局部变量，RequestQueue中有Request数组，Lift类会以Request为参数并生成它的局部变量。有三个类依赖RequestQueue类：Floor会往其中加请求，Lift会加请求并调用一些方法，Scheduler会从其中取出请求给Lift。
写的不好，没有度量。（度量也是一片红）
我的Bug
第二次作业规定了要五个类，我花了很长时间去想这些类之间的关系，最终决定用Request作为主类并读取输入信息分别送给Lift和Floor，RequestQueue作为队列类并存有关于队列处理的方法，Scheduler选择请求送给Lift,Lift将输入的请求进队、并对得到的执行请求做出响应，Floor将输入的楼层请求进队。
在动手写代码前我已经在纸上大致画了画各类的关联，因此写起来比较顺手，也感觉到自己还蛮面向对象的233
公测都过了，互测的同学报了一个没有UTF-8的Bug，我看指导书的时候的确注意到了这点，但是自己以为自己是的，就没管了，还是不够仔细。
同学的Bug
拿到的同学功能测试的树都点亮了，于是我从他的输入方面入手，找到了几个问题：
- 他使用find()来匹配正则表达式，但他的正则表达式前面没有“^”，最后也没有“$”，因此一个正确的输入前面或后面有别的字符的话他是没有办法报错的。
-
([1-9]|10)?
上面是他的正则表达式中匹配楼层的部分，可以看到他多加了“？”，当输入中不含楼层信息时程序会直接crash掉。
总结
这一次作业感觉才步入正轨，写了个算得上是面向对象的程序。使用了正确的正则表达式，没有出现一个方法里代码过长的情况。但仍然有些许不足：为了强行用Floor类而复用了Lift一个方法的代码，有些多余；每个类的方法安排似乎不太妥当，关键方法基本都是队列类实现的，Scheduler类似乎没用上。
第三次作业
类图
分析：和第二次作业一样，Floor、Lift、RequestQueue类依赖Request类。Lift类实现了elevator接口，接口内方法参数类型为Request，因此此接口也依赖Request。有四个类依赖RequestQueue类：Lift、Floor同第二次作业，新的SmartScheduler继承了老的Scheduler类，都依赖RequestQueue。
度量
胡乱分析：可以看到两个红的地方：第一个是圈复杂度高，此方法判断捎带，因此有个for循环，最大的if嵌套达到了四层，因此程序很难维护。第二个红的同样是这个函数,嵌套层数太多，问题应该是if判断太多，应该简化一下判断，抽象出一些方法。
我的Bug
第三次作业在第二次的基础上增加了捎带，一下子就难了很多。我用了最简单的方法：根据主请求去找要捎带的，放入队列2并排序，之后执行队列2的内容时也时时更新队列2的内容。同样也先“纸上谈兵”把主要方法写了出来，最后写代码的时候需要什么函数就写下来，过会儿再去实现。周二晚上的时候我发现我的执行过程出了点问题，又摒弃了前面写的，静下心来想了一遍流程，结果不知道动了哪个地方，导致有更多的错误出现。临近DDL的时候还是不要乱改程序了T^T幸好我每改一次都会push上去，所以找到了改之前的版本，加了一个if就解决了问题。
公测都过了，互测没有被找到Bug。
同学的Bug
这次的同学错了两个公测，粗看了他的程序，我觉得应该没什么大问题，就不想照着树一个一个构造了，拿我有的几个数据给他测了一下，发现两个问题：
- 同一层完成了多个请求时没有按输入顺序输出：这个Bug我之前的程序也有，我用了个取巧的方法：输入的时候就给每个指令编号，按序号输出。
- 第二个问题是我拿长数据测的时候发现的。幸好他出错的地方不在最后（捂脸）他对请求发出的时间和前一个请求完成时间的判断写的不对。
总结
第三次作业我在第二次作业的基础上写的，遗憾的是对继承和接口的运用并不好，只是因为被要求这么做而做了个表面功夫。继承是因为第二次的调度器其实没什么用，第三次必须得重写。但现在我还没有理解如何运用接口。第三次作业我的Bug不多，但都涉及到我的设计结构，因此花了很多心思在原有的基础上做改动。
一些感悟
OO也写了三次了，对于怎样花很长时间揣摩指导书、花很长时间纸上谈兵、花很长时间Debug、花很短时间给别人找Bug也有一些体会了。最要紧的应该就是紧跟issue和群聊大家提的问题吧，看到助教的回复就像美国法院大法官解释宪法一样2333其次try catch一定得加。其次是觉得自己蛮适合在纸上写个outlet的，真·纸上编程。还有就是很喜欢OO截止之前大家一起共享自己的测试集一起通力消除Bug的气氛。最后关于这种互测，我觉得就一定要做好自己吧，一定尽力保证我的程序的正确性。虽然我很想像某些同学一样，不给别人挑错，但我并不像大佬们一样能保证自己程序不会错，而且转念一想：如果我报的错让他修补上了一个bug好像也挺好的。所以三次作业的后两次我都尽力去帮着找错了，希望能帮到那位同学吧。