第一次作业：
第一次oo作业要求我们对于一个规定结构下的多项式进行加减运算，要求使用java和c两种语言进行编程。之前并未接触过面向对象的语言，也未了解过java语言，所以便选择先使用c语言理清思路，完成功能上的设计。不得不说这和以往较为死板的编程题目已经有个很大的区别，我不得不花费大量的时间去思考并整理非法输入所带来的的问题，这也许也是第一次作业中遇到的最大的困难。在之后的java编程中，在无论是经验或是对于面向对象的理解都有所欠缺的情况下，虽然还是把程序写了出来，但更像是披着面向对象的皮，干着面向过程的事。
在开始动手前，还是花费了大量的时间去阅读指导书，对于其中很多细节部分都与周围人做了深入的讨论，以确保万无一失。不得不说这一项任务的工作量甚至要超过之后的编码过程。我觉得这一点是这门课最让人头疼的地方之一，但却也是最有魅力的地方之一。正如吴际老师说的那样，在以后我们如果从事相关行业，客户的需求远远无法细化到现在作业的标准，那么如何去提高自己代码的鲁棒性和容错性，就是一名优秀程序员所应该具备的素质。在这一过程中的思考、分析、争辩，让我对于题目，对于编程都有了更加深刻的理解，更学会了如何在合作中学习，正所谓“众人拾柴火焰高”。
基于度量分析：
第一次作业也只使用了两个类，分别为Poly和main，main函数进行数据的读入与输出，也进行了多项式格式的判断，Poly类主要用于数据的存放于运算。可以看出，本次作业并没有完全体现出面向对象的味道，对于类的定位也不准确，该拆分的功能未进行拆分，该保留的功能可能并未保留。表面上虽然完成了此次作业，但质量并不高。不过作为第一次oo作业，还是帮助我较为深刻地了解了面向对象编程的方法、目的以及优势所在，在之后的学习中，面向对象编程逐渐变得得心应手。
bug分析及互测策略：第一次作业的bug主要集中于对于非法输入的处理。第一次使用java的我并未使用正则表达式，而选择了类似计组中“状态机”的表示方法，不断去扫描输入的字符，来判断是否符合规范。不得不说这种方法在格式较为复杂的情况下会变得十分混乱，并且容易出错。虽然我使用了大量的测试用例，但却仍然在互测中出现了bug。同样的，我接受到的作业，即使使用了正则表达式，由于处理不当，也出现了一些不合理的输出。可以看出，同学们对于这样的编程方式普遍有所陌生，主要的问题也集中在了对于不合法输入的处理上。
第二次作业：
本次作业的任务是运用java实现一部“傻瓜电梯”的运转。通过第一次作业的训练，我对于面向对象编程有了一定的认识，在本次编程中思路也变得清晰了许多。在本次作业中我一共使用了五个类，并将电梯的运转分工在这五个类中。其中电梯和楼层类负责发出指令，Request和Rqueue分别进行指令格式的检查与队列处理。但美中不足的是，在调度器类中，不仅完成了对于电梯运转的调整，也包括了对于程序的输入与输出，从而造成了功能上的混乱。对于之后的调试与修改带来了一定的麻烦。
这次作业真的算是很刺激的一次作业了。在作业发布后，我由于身体原因，以及医院令人惊讶的低效率，我在医院进行了长达4天的检查，且大部分时间都浪费在了跑路上。眼看ddl将至，而自己的代码空空如也，真有种想把医院拆了的感觉。为了能及时交上作业，我不得不在赶路的过程中思考自己如何编码，思考自己会遇见怎样的bug，之后也不得不在车上架起笔记本电脑，噼里啪啦地打起来，并终于在ddl前提交上了自己的代码。不得不说，这一经历还是挺有感触的，即使是现在想起来也觉得有点佩服当时的自己。这次的作业让我发现了两个事情，第一个就是，在编码前仔细思考，仔细分析，不要急于编码，反而可以达到“磨刀不误砍柴工”的效果，在经过长时间思考后，我的编码过程变得十分流畅，几乎是一气呵成，而不像往日里写写停停。当然了，也有弊端，由于是在车上打代码，干扰比较多，心情又很乱，写出来的代码就存在了很多隐藏bug，幸好回校后及时拯救了一波，不然就真凉凉了哈哈。
基于度量分析：
bug分析及互测策略：有了上次作业的经验，同学们对于非法输入的处理变得熟练了许多，本次测试的重点也从格式错误转为了功能测试。由于电梯运转情况十分复杂，遇到的变化也千奇百怪，所以要想写出十分鲁棒的代码并不是一件容易的事，需要测试者进行足够的分析总结，仅仅依靠课程所给的分支树是远远不够的。测试时，较为极端的例子，比如处于临界点的样例，以及数据大量的，组合多样的样例，很容易检测出程序中所隐藏的bug
第三次作业：
本次作业改动不大，是在基于第二次作业的基础上，更改调度器的调度方法，并微调了数据的输出方法，同时考察了同学们对于继承和接口的理解与运用。总体来讲和第二次作业差不多，但这时我在第二次作业埋下的隐患就体现了出来。由于并没有对于类的功能进行很好的规划，甚至将调度器直接放在了main函数中，本次的改动就让我真正体会到了“牵一发而动全身”的感觉。许多同学可能只是对于调度方法进行了微调，我却因此有了从调度器到电梯到楼层的一连串修改。本次作业让我深深感受到了对于类功能定位的重要性，如果将过多的职能都放入在一个类里，打造出一个“上帝类”，那么对于维护和调试都会带来数不尽的麻烦
bug分析及互测策略：本次作业的测试重点与第二次作业相同，但工作量显然多了许多，因为电梯功能的提升带来了大量的特殊情境，同时也带来了更多的测试样例。如何将特殊情境一一排查出是本次作业是否能取得理想分数的关键。
心得体会：经过三次作业的洗礼，我的心得主要可以概括为两点
1.在设计程序的时候一定要用心，对于每一个类的规划都要十分明确，避免一个类从头忙到尾，或者一个类只有个空架子。每一个部分都该有它应有的职能，做自己应该做的事。如果不提前做好规划，在之后进行修改的过程中就会遇到数不尽的麻烦，甚至会因此产生更多的bug。所以，对于每一部分的定位显得至关重要
2.oo课程带给我另一个收获应该就是全局观。对于一个项目，会产生许多意想不到的问题，如何去将问题细化并分类，是完成本次任务质量好坏的关键因素。我们应该去花费一定的时间，仔细思考出现的情境，并重点对于边界条件进行检查。
最后想写点对于oo评判机制的看法。我不能一昧地说现在这样的机制好或者不好，我只想理性去分析这种机制的利弊。先说说利吧，首先这种机制对于同学们的能力提升真的很重要，能迫使同学们更加认真地对待每一次作业，能更加认真地去分析，去理解，从头到尾领悟题目的本质，细化到每一个小细节，这和以前的练习是完全不同的，至少在完成这三次作业后，我自己感觉编码能力得到了挺大的提升。其次，这种机制也提前引入了竞争的因素，能够提前帮助同学们适应以后社会上残酷的竞争。但也正是因为如此，这种机制在一定程度上可能会影响同学们的友谊、情绪，有的同学还借着匿名的机会出言不逊，甚至明里暗里使用一些讽刺性的言语，我相信这绝对不是这门课程所设计的初衷。
还是挺喜欢这门课程所带来的的东西，挺喜欢这种有趣的互评机制，但还是希望它能够做的更完善，更好，让每一个想学知识的同学能够更快乐地学习，更高效地学习，而不是每次互评完都会生一肚子火。
加油吧，我们的路还很长，oo不是终点，而是起点。
