第一次作业：
Metrics度量分析
博主第一次面向对象的java代码分析：第一次作业的目的是由面向过程到面向对象过渡，了解两者之间的区别。由于第一次写面向对象的代码，难免会有面向过程的习惯，正如有些同学调侃道：假装面向对象。博主的第一次作业的代码中也能明显看到过程化编程的痕迹，比如关于输入内容的处理，判断与转化，这部分功能我直接在main函数中用了过程化编程实现，没有封装成一个单独的类，。其他的功能的实现，我参考了老师ppt上给出的结构样例及方法，因此看起来像面向对象。第一次作业我有11个bug,准确来说是两个bug;第一个bug:正则表达式匹配时爆栈了，虽然写代码的时候知道有这个bug,但是无奈正则表达式不熟悉，而且写了一天代码没吃饭饿晕了，不想写了。另外10个bug,也就是第二个bug:输入格式错误要输出"ERROR",结果我有一个地方把"ERROR"写成了"ERROE",碰巧那个地方在我的设计思路里是匹配较多格式错误的输出，就莫名多了10个bug。Mtrics数据分析中标红的部分应该深度分析方面有点问题，本人设计思路方面属于比较求稳，面面俱到，宁可重复，也不漏掉一种可能情况，因此造成了循环和嵌套得比较多。接下来的两次作业也是属于循环嵌套比较多。分配给我的测试代码是个大佬的，找不出错误；
博主第二次作业的java代码分析：设计思路：先将所有的指令输入进行处理，包括判断，转化，生成相应的电梯指令，并将生成的电梯指令加入到指令数组中，然后通过schedule类进行统一处理并输出结果。由于指导书的硬性要求，必须要有5个类，博主各个类的功能方法看起来也还算比较分布均匀，当然，有了第一次作业的心得，我增加了一个Judge来专门处理输入，判断和转换问题。第二次作业刚完成的时候判断部分有些冗余，重复代码行比较多，删减了大约100行，主要是思路不清，考虑不全。细看博主的代码结构，可以发现，方法中set,get方法占了很大的比重，各个类的属性虽然定义为了private,但更改还是主要在其他类里面进行，自闭性不强。由于第二次作业考虑周到，因此第二次作业没有bug,分配给我的测试代码又是一个大佬的，没找到bug.
博主第三次作业代码分析：代码思路和第二次的相同。先写点心里体会吧，前两次的指导书看完了基本就能有思路了，整体架构能够出来，需要做的就是一些细节方面的理解和补充，第三次的指导书我看一天还不知道怎么动笔，然后是边想边写。当然最后还是勉强把架构搭起来了，相比于第二次的代码，我第三次只改了两个类，一个是电梯类，一个是添加了schedule的子类son。这两个类是大象类，电梯类属性多，set,get方法多，son类的run方法足足有300行，没办法，虽然丑点，总比写不出要强点。电梯类冗余主要是因为第二次作业的属性定义不敢去更改（构造电梯有效指令的功能里用到了原来的属性，而电梯指令构造方法没有做改动），只能定义更多的其他属性来记录相关的状态和标记；说实话，ALS电梯调度真的有点复杂，考虑到的情况有限，到后来写完了拿别人的数据一测就能发现不少bug,所以son的run方法里面电梯调度方案增加了一些针对调试中发现的bug而做出的补丁代码，显得有些无序。由于我测试代码没按照给出的分支树构造，因此漏掉了要考虑的情况，另外，发现的bug也并没有全部调试出来，有一个bug我调试了改了整整一天也没有改过来，看来是改不出了，主要是一个标志物的值在某条不相干的指令执行后竟然改变了，导致后来的指令判断发生错误，为了下一次的多线程，我还是得重新写run方法。这一次我的代码有两个bug,一个是输出顺序没完全弄清楚，导致顺序错误，第二个就是我改了一天都没改出来的bug。感觉第三次指导书还是有点问题，对同质请求，满足捎带条件的请求的举例不够多，大多数的情况都得从issues和助教口中亲口获得，或许是我个人的理解能力不行吧。另外，本人的设计思路比较传统，由于某条输入时间靠前的指令竟然可能被输入时间靠后的指令所携带，所以我用了三层for循环，也是够拼的，还好只需要处理100条指令，否则我都要考虑运行时间内能不能有结果。总之，就是我的设计方面应该改进并优化一下。我测的代码还是个大佬的，又是零错误（我要得负分了，笑哭.jpg）。麻烦下次给我一个有错误的代码，最起码别让我负分。
心得体会：
1：不要把多个类写在一个class里面，调试起来会很痛苦（尤其是像我这种只会System.out调试的人），代码写到1000行的时候，上下翻看都困难。
2：不要急着动手，想得越清楚，理解得越透彻，写出的代码结构更严谨，需要更改的地方就少。