写在前面
三周前，自己对于java程序真的没有太多的了解，连基本的输入输出都不会，至今清晰记得写第一次作业时的无奈；到了第二次作业，在了解了java的基本语法结构以及通读指导书的基础上，很快便完成了作业目标；而第三次作业，粗略浏览指导书的内容后，“认为”这次作业仅仅就是在上次作业的基础上做小幅修改，结果打脸打得巨响……三次作业，从对接受新语言时的彷徨、到基本掌握并小试身手的满足，最后经历“低估”作业内容以致写程序时的绝望——三种不同的感受，让我对java的初次体验记忆深刻。
第一次作业 在彷徨中前行
第一次作业，可以说是在完全不了解java语言的情况下，硬着头皮写出来的。这次作业只有一个类Main；里面的代码与C程序除了输入输出等特定系统调用外大同小异，只将一些功能“意思”地拆分成了几个方法。所以就不贴度量分析和类图了。但这次作业最大的收获是初步掌握了正则表达式的用法以及java中一些常用的函数；同时，虽然这次作业是按着面向过程写的，但在拆分方法的过程中，这次作业在潜移默化地向我传输“面向对象”的思想，也为第二次作业的顺利完成做了铺垫。
这次作业的bug主要存在于自己的正则表达式还存在着缺陷以及边界情况的考虑问题；前者应在自己构造测试用例时检查，后者则让我学会了try-catch的使用。此外，第一次作业还让我明白了非常非常重要的两点：一：一定要认真看指导书！互测时我拿到的那位同学就是因为将“ERROR”输出为了“error”导致公测红了一大片………………这也给我挑bug造成了不少困难，因为剩下的可挑bug的点已经不多了；二：认真写readme！最后我给这位同学挑出一个，即前导+00..的处理，就是钻了readme的“空子”。
第二次作业 小试身手后的满足
通过慕课、CSDN等网络资源的利用，在第二次作业开始之前初步掌握了java的基本结构。因此，本次作业写下来感觉还是比较顺利，也算自己第一个真正意义上的面向对象程序。本次指导书规定必须要将程序分成至少五个类来执行，在此基础上我增加了一个Main类作为程序执行的入口。类图以及度量如下：
优点：
写得快算是一个优点吗……………………由于本次作业在写作前进行了充分的构思，所以一个晚上就将基本功能写得差不多了；之后又花了一个晚上进行后期的“修补”和测试。对自己而言已经写得很快了，尤其是和第一次以及第三次作业比较。至于程序本身的优点，与自己比，这次程序在“面向对象”这一思想上有了很大的进步，不像第一次作业一样一个类进行到底，难以维护。
缺点：
尽管与第一次作业相比，已经有了一些“面向对象”的意思，但还是暴露出来问题：首先，在程序的六个类中，调度器类和楼层类成了“酱油类”——这两个类在我第二次作业的程序中基本上没有用到。相反，从度量图中也能看到，Nested Block Depth很高，其他四个类，除了电梯、指令、指令队列定义了基本属性和方法外，其他大部分的实现都写在了Main类的main函数里。这也给第三次作业的设计带来了麻烦。main函数里使用do-while循环来读入控制台的输入，每次循环中都有着大量的if-else判断。解决方法可以是将这些if-else判断作为方法从main中分离。
Bug分析：
这次作业公测时没有出现问题，互测阶段也没有被挑出bug，这让我有点意外。再接再厉，努力保持下去吧。
第三次作业 在绝望中挣扎：
第三次作业有点极限操作的味道：在周五的课上老师最后布置作业时，浏览了一遍要求后心里想着也就是加一个捎带的功能而已，所以就没想着早点开始做。结果周一晚上开始着手写第三次作业时仅仅是思考算法和程序结构就用了将近四个小时，一晚上过去以后基本上没怎么写；到了周二晚上构思得差不多，写了一晚上想着回寝室放松一下，和室友讨论并试着跑了跑室友构建的样例后才发现自己有很多情况没有考虑。周三白天没课，一直在调试自己的程序；但每当修复了一个bug后又会新出来另一个bug，颇有点拆东墙补西墙的感觉......到了傍晚临近ddl时才勉强完成，交上去后也不敢想象公测结果会是怎样，这种绝望的感觉真的难以忘怀。虽然最后完成了作业，但代价就是我的代码非常臃肿，结构甚至比第二次作业还要糟糕一些；Floor类没有实际意义，Scheduler子类Sche则有上百行代码，其中有很多重复内容。类图如下：
优点：
算法上在扫描同质指令时以时间作为循环变量，每执行一条指令以及判断捎带指令前判断一次同质，有效避免了同质指令判断遗漏或误判的情况；在执行指令时以楼层作为循环变量，既保证了指令的执行符合楼层的顺序而非时间顺序，又能筛出下一轮主指令。
缺点：
如上所言，由于本次作业写得比较仓促，致使代码极其臃肿，这也使得debug有些困难。此外，未将重复性代码作为方法分割出来，使得代码在阅读时不够友好。同时，Floor类还是一个摆设，未赋予实际意义，无疑这些都会给下一次多线程作业带来困难。与第二次作业一样，虽然本次将主要算法由main移到了Sche里，但由于时间安排不当以及经验、代码风格问题，在judge方法中嵌套了过多的循环用于判断同质、捎带，可以试着将这些判断代码作为方法从judge中分离。
Bug：
本次作业公测与互测中共有一处关于捎带指令的bug，即ER型的电梯内指令的目标楼层可以位于电梯当前楼层与电梯目标楼层的范围之外。这一点在指导书上写得很明确，自己在写程序之初也确实考虑到了，但在后期debug过程中被“de”掉了...出现这样的低级错误还是因为自己的代码风格不够简洁、规范，以致每当de完一个bug后很少能够发现正常功能意外去除的情况。当然，自己未安排好作业时间，导致后期工作非常急促也是一个原因。
心得：
1.作业一定要早点开始写，否则到后面作业来不及交时会有恐怖的想法冒出来………………
2.代码风格力求简洁，既方便自己debug，也方便他人阅读，勤写注释。
3.在动手写代码前一定要构思好，哪怕懒得写to-do-list也得清晰地知道自己打算实现的算法。
4.每次作业都按照课件上推荐的结构来写，否则如果下次作业是在本次作业的基础上改的话会很头疼。
5.还有时候不逼自己一下，还真不知道自己能写得出来。
6.有些事情咬咬牙就过去了，做得时候多痛苦，坚持下去，完成后就有多轻松。
