第一次作业
1. 度量分析
（1）OO度量
（2）类图
（3）自我点评
本次作业的主要内容是读取字符串、判断合法性以及实现简单运算，难度不大。
因为是第一次用Java语言写程序，于我而言最大的困难应该是从“过程”到“对象”这种认知思维的转变。尽管按照老师的要求抽象出了两个类，但代码量庞大的main函数还是说明这是一次不那么成功的“面向对象”。如果能再改进的话，应该可以将输入的过程分配到单独的“input”类中处理，让工程整体更加平均，对象的条理性更突显。
2. 本程序bug分析
本次作业公测所有测试样例点全部通过，互测没有被发现bug。但是仍然存在一点问题，就是try-catch方法运用的范围过小，如果测试者数据极大，不确定是否会出现Crash，所以往后的异常处理范围全部扩大至整个main了。
3. 测试程序bug分析
测试的策略主要是基本功能能否实现→字符格式判断是否精准→程序是否稳定。没有结合代码设计结构测试，以后会注意。
本次测试任务作业公测出现两个bug，都是字符合法检验出现的错误，主要问题在正则表达式代码部分。该程序对正确字符串进行计算是没有问题的，但在容错检测时发现了程序遇到“-0”指数会报错，这个点助教们曾经在群里讨论并通知过，而该同学没有在Readme中单独说明，所以判定了一个ERROR。
第二次作业
1. 度量分析
（1）OO度量
（2）类图
（3）自我点评
本次作业主要内容是实现单部“傻瓜”电梯运作，难点为算法层面的“同质判断”与结构层面的“五类协调”。
虽然按照规定勉强划分了五个类别，但是从类图上可以看出楼层类形同虚设，根本原因就是我的“过程式思想”：每次得到电梯状态和队列中的请求，假装调度后改变状态实现响应，周而往复。从读入的请求字符串开始，我就把这些请求完完全全当成了数组成员，将所有属性信息都归纳在自己的类里，每个请求发出时，并不是“电梯”或者“楼层”有反应，而是仅仅在“队列”中添加了一个蕴含字符串信息的“请求”对象，而整个过程的实现也就是根据“队列”改变“电梯”，得到符合要求的输出即可。因此，整个工程的代码分配及其不均衡，也因为操作过于集中而导致main函数复杂性较高。
2. 本程序bug分析
本次作业公测全部通过，互测阶段最终被报了两个令我哭笑不得的自定义bug，主要是因为Readme没有push上，测试者有理由依据自身理解判断。吃一堑长一智，在之后的作业里我选择了更保险的Readme提交方法，并且在截止时间前下载作业检查文件是否齐全。
然而在第三次作业debug过程中，我戏剧性地发现了我与互测者都忽略的问题：在判断UP/DOWN搭配错误时直接用字符而非用转换后的整型数来匹配楼层，导致对于(FR,+ 1,DOWN,0)等类似的指令是不会报错的。也许我应该为逃过了扣分而感到幸运，但这仍然暴露了我对细节的处理还是不够严谨，自测不够全面，也为以后的作业枪响了警钟。
3. 测试程序bug分析
测试的策略是基本功能能否实现→字符格式判断是否精准→同质判断是否正确→程序是否稳定。
本次测试任务作业公测全部通过，测试时并未发现问题。
第三次作业
1. 度量分析
（1）OO度量
（2）类图
（3）自我点评
本次作业的主要内容是在上一次作业的基础上进行扩展，实现单部“智能”电梯运作，难点为算法实现“捎带”。
由OO度量的结果可见，这次作业的整体架构并不是很优良。主要原因有几点：一是与从第一次作业就出现的问题，输入判断依然是在main函数中实现，而main直接放在了passing类中，为了数据访问的方便将某些类直接作为它的属性变量，导致该类代码较为臃肿，块嵌套过深；二可能是由于自身选择的捎带算法属于保守型，没有考虑效率，循环较多。
2. 本程序bug分析
本次作业公测互测皆安全通过，但是在自身代码调试阶段出现了很多问题，比如遍历队列时条件考虑不全、同理方法在改动时只改了其中一个、对指导书理解偏差导致出现puzzle等。不过正是因为这次的作业较为复杂，仅用输出调试困难，让我有机会运用Eclipse的debug模式更加有条理地查错纠错。
3. 测试程序bug分析
测试的策略是字符格式判断是否精准→同质判断是否正确→捎带功能能否实现→程序是否稳定。
本次测试任务作业公测出现了4个bug，均是由于输出格式失误导致的，有些可惜。
总结感想
1. 知识层面
1）正则表达式
正则表达式是一种处理字符串输入的高效简洁的方法，在三次作业中都起到了非常重要的作用。通过阅读助教提供的菜鸟教程（http://www.runoob.com/java/java-regular-expressions.html），我们在短时间内掌握了其基础的使用方法，并应用在程序中。如果我们想让输入符合某种特定模式，正则表达式是最优的选择，仍然使用“有限状态机”来处理只会耗费不必要的精力。
2）Java入门：类、方法、继承、接口
对于一个名副其实的Java小白而言，面向对象的大门还真没那么好进。一开始为了便于理解，我把class当做是C语言里的struct，或者说是更有仪式感的“struct”。这个“struct”一般要占一整个文件，里面的变量不是加个.就能访问的，必须有私有前缀，除此之外还需添加各种各样的“function”（method）……接着创建了第一个Poly类、构造第一个addTerms方法，自以为很“对象”了，结果写完main一看还是个“过程”。第二次作业建了五个类，尝试着把各自的属性划分到类里操作，但是却分得不够均衡，工程像个身材扭曲的怪物，还是留有“过程思想”的残余。最后了解了类与类之间的关系，在原有父类的基础上继承出了子类，为电梯运动添加了接口，虽然勉强完成了任务，但对于程序本身来讲存在感并不是很强，有点“强行凑合”的意味。
emm总结下来就是：知识都懂，运用不通。
3）调试方法
前两次作业的调试方法是System.out输出型，由于第三次作业的复杂性，改用了Eclipse的Debug功能。两种方法各有优点，各有适合运用的场景。在Debug模式下可以更直观地观察所有变量的变化情况，设置断点按行运行也是找出Exception根源的利器；printf简单粗暴，但在后面的多线程程序调试时会起到更加重要的作用。
2. 架构层面
上文中已经提到了很多次“对象思维”，此处就不再赘述了。除此之外，还想谈一谈“先设计后编程”的重要性。
记得第一次课，吴际老师就跟我们建议过写作业之前先在纸上大致写下整体的结构，包括需要什么类、每个类管理哪些属性、需要哪些方法调用、类和类之间如何联系等等，最后一步才是打开IDE敲代码。然而由于前几次作业心态比较焦躁，我没能平静下来先理思路，一直都是边想边写边改的策略，导致写着写着才发现形式上的“对象”实则变了味道，只能暂时抛弃优化架构的想法，以正确输出作为最后的底线。其实一份代码的评价标准并不仅仅依赖于结果的正确与否（虽然这也很重要），它的结构和效率才更能体现出编程水平与思维能力。
希望下一次总结时能在这些方面能有所进步吧:)