作业1：多项式加法
这是一个从未接触过JAVA源码，未接触过OO思想的，未了解6系OO这门课到底有多可怕的三无人士的血泪史的开始。
于是这次说是让大家熟悉java的多项式加法逼得我三天学习一门新语言，总算是在各路神仙的加护下苟活着呢。
这次作业的类图我就不贴了，相当丢人。现在回头看来，第一次写的就是个面向过程的玩意。一个主类，主方法，带了一个冒泡排序方法（输出要按照指数升序吧）和一个筛选插入的下一项指数是否为负的方法。输入输出计算全都放一起了，真亏自己当时没看花眼。
被揪出来的bug，一是死在了一个magic number上，搞到后面变成只支持19个多项式了；二是输出时判断系数是否为0那里的逻辑设计的不好，简单的一个先判断0再输出就OK我却搞成了乱七八糟的复杂玩意。（即使现在对着当时的注释也没看懂我当时在干嘛）核心部分还是没啥大问题。现在感到蛋疼的一点就是，当时没怎么写注释，现在读起来感觉有点摸不着头脑，只能胡乱分析.jpg了
我拿到的那位大神的代码还是挺厉害的。虽然同样是面向过程的JAVA，但是基本功比我要优秀，公测只错了一个。我分析输入用的是正则表达式（对，也是一天速成的，照着以前用过的一个Firefox插件里面的设置页面自带的一图看懂正则表达式撸的），这位大神手搓了个状态机，洋洋洒洒百来行。后面给TA挑了什么bug记不清了，当时也没多想，记录什么的都没有，现在回去翻课程网站已经看不到了。总之是对着源码中的数组越界啊，对着readme看看有没有不一致的地方找（快住手这根本就不是决斗debug）。
作业2&3：单部电梯模拟
总之第一次作业真是做的一团糟，也debug到了离DDL不到半个钟的紧急时候。这次作业开始，指导书膨胀了，条目比上次多了不是一点两点。
为了对付膨胀的指导书，我只能搞个TXT作为我的to do list。这个工作真的花了我大半天，因为不仅要对付指导书，还要对付gitlab的issue上面的一些详细解释，还有群聊天记录中助教的新解释。把这些内容吃透以后，如果我的智商跟得上的话，那么再花个小半天，程序的设计逻辑就出来了，能具体到每个情况下的分支的具体操作和原理。这种操作源自上个学期计组教的工程化方法。先做设计，而不是先打开IDE瞎码一通，出毛病了再改，改得面目全非，git仓库里面版本迭代了不知多少回……从效果上看，真的很棒。设计两三天，编程一晚上，debug一上午（因为设计做好了，注释写的也比之前充足，本应基本上没什么bug）
这次的设计就开始有OO的影子了（面向请求编程） 其中最难的地方还是调度逻辑怎么从自然语言转换为JAVA代码。逼着自己把流程图画出来以后就基本上OK了。类的设计其实不好，Request里面区分电梯和楼层的请求不是通过继承（那个时候还没学，不会）而是暴力地放一起，实际上内存开销会变大，而且调用类中类的属性getter的时候，代码就会变得又长又丑，可读性不好（侧面促进了我的注释的详细程度www）
最后出公测结果都傻眼了，明明是第一次这么有1a的感觉，明明是第一次在OO课使用工程化方法，两件快乐的事情重合到一起，获得的本应是高通过率的喜悦，可是为什么还是wa了7个呢。それわ、没计算停靠结束以后时间要加上开关门用的1s才能接着走，全面崩盘啊（自己测都没测出来这么明显的bug，真是感觉太好膨胀了）
这回我拿到的代码，大体上也没什么问题，主要是和指导书有点不一致。还有一个就是，明明使用了定长数组，却没有对写入做限制，也没有try catch，很明显的一个数组越界Crash（这时就要赞美ArrayList了）
总之，这第二次作业开始，JAVA算是更熟练了吧，越来越有OO的味道了（身体倒是也变差了），也逐步完善了自己做OO的流程：花上一天啃指导书，再来一天做设计，并验证设计的正确性（需要例子支持，这个比较困难），写代码&debug……唉，即使如此每次都会因为指导书里面的一个小点没顾及到出bug
第三次作业是继承自第二次作业的，工作量少了不少，但是核心部分却要重写了——加入了捎带功能。这个新功能的加入可真是要命。首先彻底搞懂每种情况下的捎带情况和运行挺费劲的（最后还是漏了一个小点）。其次，复杂性的增长迫使我把原来的按照指令直接运行改成了步进式的模拟，一层一层来找是否要停靠，停靠的话是否有同质请求，循环嵌套就来了。不过还是因为事前准备工作做的比较充分，写代码没花多久，测试起来也没有致命的bug。只是被测我的那位同学找出了输出顺序上的一点小问题（在此感谢~）
虽然第二次作业中就有了类中类的浪费内存的行为，感觉重构花费的代价不划算就没动了……复杂的单层模拟，多层循环的嵌套，注释的比例差不多到了一行一条了，当然写注释绝对不是赔本生意就是咯。
这回我拿到的那位同学的代码也是一如既往的优秀，功能上可以说是很全面了，只是没按照指导书的要求做interface就很可惜（也许是因为这次的作业跟接口的特性相性确实没那么好吧）
心得体会
1.累。学姐说第一次多线程才开始通宵，为啥我才做到单部ALS就要熬到5点呢，明明我没有拖延啊……唉
2.设计文档真的不能瞎掰（我老是照着自己某一阶段的想法去写文档，懒得跟自己最终实现做对照，然后就吃亏了）
3.如果是计组大体上治好了我的拖延症，那么OO是根除了我这个毛病。不花上足够的时间的话，就连要做什么都不知道。
4.从我个人的习惯来看，事前设计真的很重要，再怎么详尽都不为过。设计做得好才有机会睡好觉。（因为设计一团糟最后被无尽bug制逼得全部推倒重来反倒是最没效率的）我倒觉得，这种流程更适合普通人。私以为，编程上，大神一步可以完成的事情，普通人通过步骤分解，分成几步力所能及的子事件，每一步认真去做，最终能达到相同的功能。这绝不是自卑，而是因地制宜。
5.测试苦手，还真是没什么好办法。写脚本又不会写，又没法自动生成标准输出，只有靠在分支数上修仙才能勉强不被无效维持生活这样子。设计做的足够好的话，debug的工作就会大大减轻，然后就容易偷懒了（明知道偷懒只会放过藏得深的bug，可是还是忍不住。啊，脆弱的人性）这其实还有点磨砺意志……
6.最后一条，献给各位同样是面对这门课就感到想死的同学。曾经我也想过一了百了，但是我还是挺过来了。不要在意今天dalao又做了多少多少，人比人气死人。虽然可能你觉得如今的自己能活着就已经是奇迹了，但是要相信能让奇迹变成“连续发生的奇迹”的力量，永远不会背叛自己。能做到自己当前要做的事情就是胜利。实在不行也可以想的简单点，不进补给站就是胜利。虽然真正理解你的内心的痛苦的人可能找不到，但是你永远不会是最惨的那一个，至少你还有选择自己生命何去何从的权利。那么，为了不让跨越了无数难关的你曾付出的心血付之东流，请永远不要丢掉那份向难题发起挑战的勇气。
坚持住，接受试炼的同袍们！