BUAAOO第四单元及课程总结
本单元架构设计与总结
要求：
实现UML图的解析器，能够解读类图，顺序图和状态图的大部分属性，同时需要能够根据三条简单的规则判断类图是否符合一定的规则
架构实现：
本单元作业我认为重点在于理解UML图的基本使用和属性，以及使用java实现复杂数据结构的管理。
-
node是所有UMLElement的父亲，保留一些基础的操作和通用属性，UML各个element都对应了一个Myelement
-
对于每个新Node，将所有的id解析为对应的node，再存储，node之间相互拥有。形成树状结构。
-
对于循环操作，大部分采用了floyd算法，或者递归算法。
-
使用了三个handler类，共同属于一个总handler类，没有采用继承的方法，以防止某个类过于臃肿。
-
对于不关心的element，没有进行实现，既保证了架构上易于扩展，又不至于分散注意力。
-
依然使用了冗余数据存储，以方便对同一个元素不同方式的查询
走过的坑：
-
原来数据组织是线性的，不方便维护和解耦。所有的节点都存储属性节点的Id,最后在顶层父类查询id得到节点，这样做的初衷是方便通过名字查找类，但实际上并没有实现这一目的，徒增了顶层类的复杂度和维护的困难性
-
folyd算法没有注意嵌套的顺序导致循环不够充分。
-
未能注意到扩展性的重要性，对于endpoint的出现束手无策。其实我一开始预留了endpoint的位置，但是由于没有实现，和mylifeline不能兼容，因此出错。最根本的原因是，我发现endpoint时未能探究到它是可以和message交互的，测试数据的不充分导致了这次bug的出现。
尚需提升的代码能力：
-
打造强悍测试数据的能力。这次之所以强测挂这么多，主要是因为自己根本没有造测试数据，全靠脑袋想象。超出我想象的测试方法有：
-
冗余数据测试法，就是按照一定的规律生成制定的测试数据，并且在不同的位置制造可能的空指针异常。
-
围绕测试限制的边界测试法，就是比如他要测试循环，就构造多个不同的循环，尝试在测试环节大开脑洞，想出一些自己原来没有想到的测试方法
-
限制之外的测试，程序的鲁棒性往往更重要，在课程的严格限制之外，有一些没有特别说明但是真实存在的，拿出那样的数据是必要的
-
分享测试法：你把自己比较强的测试数据分享给别人，也会收到来自别人的超强数据。“大佬的识别与接近”也是以我为代表的北航银的必修课
-
-
第一想法足够经得起打击的思维能力。由于第一想法往往直接决定了整体的架构，如果最开始的架构不适合扩展，那么后来想要改掉，就像处理一个shitMountain一样难受，这次就因为开始考虑的不周全，导致后来根本不敢删掉冗余的存储方式。
-
写代码的专注力。为什么我每次写OO作业的周期那么长呢?主要就是因为真的坐不住，遇到不容易解决的问题的时候就想做点任意其他东西换届紧张。但其实完全没有用。所以真的需要学习大佬们的毅力
-
debug和分享
四个单元中架构设计和OO方法理解以及测试的演进：
架构方面：
-
在求导单元，我对架构重用的理解就是再用相似的办法把所有东西重新写一遍。为什么不直接复制呢？因为我担心上次实现的部分细节这次不适用。归根结底，是我没能将方法和类真正的解耦。由于放不开手脚，方法往往承担了超过一个的功能，仅仅在保证方法行数的限制。而且方法的命名有小问题，导致自己事后不能立刻明白自己在做什么。
-
在电梯单元在架构可扩展性上做出了很大的改进。前两次作业几乎没有大的改动（但是因为改动太小，所以忽略了很多细节）。但是第三次难度增加，我没能适应过来。我确实没想打第三次作业会增加选层。所以电梯的得到乘客的方式发生了很大的变化。这次的架构是一个管理大类，几个功能小类的形式，需要考虑线程的资源争夺问题。这次的架构应该在保证正确性的基础上兼顾性能。
-
我认为jml单元是教我们如何实现架构重用的。帮助我们重现了需要架构重用的实际场景。
容我吐槽，最后一个小节和前两个小节真的是一个单元的吗？这单元的主要难度集中在算法上。 -
在UML单元，想必也是对于架构重用的教学，我学会了除了继承的另外一种重用方法 -- 相关联。既保证了所有原来的方法都能被用到，也保证每个类的复杂性不至于很高。前提是，原来的方法不需要做任何修改，只是新增完全不相干的方法。
OO方法理解：
-
求导单元，我还是基于过程思想居多，虽然开始考虑解开各个对象之间的关系，但是实际还是只有几个类，仅限于根据名词构造类。老师提示说可以实现一个求导接口。但是直到现在才渐渐有点理解接口的意义。第三次作业的时候，由于懒得将三种递归分开，写了大量重复并且难以维护的代码。
-
电梯单元，依然是根据名词构造类。这次有努力尽量解开每个对象的负担。关于功能性的解耦也做了一部分，比如handler, lefthandler之类的，但是效果不是很理想，表现在，handler和顶层的交流以及和底层的交流相对大佬没有很方便，实现的比较复杂。没有很好地理解留下平整的接口的重要性
-
JML单元，体现了OO方法的重要性。由于节点是一个利用类的属性很好管理的东西。这个单元除了查询图的知识，主要就是考察总体对部分信息的查询能力。说明OO不仅是对现实结构的重现，更是一种优化，不仅可以按照真正的树状结构查询，还可以增加冗余的结构
-
UML单元，我自认为这节里我做得还好。可能是树状结构比较容易提取对象的原因，我能够根据功能和实体创造出复杂度分配稍微平均一点的类。不会对get,set方法产生排斥心理了。可以熟练地获取父类的各项属性。但是有些可以总结出父类的类并没有进行归纳大致大父类--NODE的孩子太多，代码重复率有点高。
测试方面：
老实说，我在测试方面的长进并不是很大，原因是每次的时间都放在了编写代码或者测试程序上了，又没有花很多时间分享，而且没有搞明白自动测试的原理。
测试可以从以下方面考虑：
-
过于简单的功能，能够确保不会出错的可以放过。
-
压力测试，用大量重复性高的数据多次测试，一般可以测出爆栈等错误
-
边界测试，从数据限制边界制造数据
-
全局测试和局部测试相结合，关于特定功能可以进行重点测试，尤其是涉及到多个对象或多个层次或多层循环的部分，应该加大测试的力度
-
编写数据生成器，控制一些比较重要的特性，可以生成比较好并且数据量大的数据
-
分享
课程收获：
-
对于java代码的掌控能力有了显著提升，最开始被很多不成熟的思想限制，比如这么多文件太麻烦了，get和set方法坚决不能传递内部的数据结构（但这样会使得数据交换和修改变得麻烦），对于一个方法总是在脑中停留非常长的时间才会开始动手做，但现在几乎是想到就可以下手码代码了。
-
增加了对算法重视。因为原来的我不懂利用已经存在的轮子，又不会算法，每次都会使用很LOW的方法实现本来很简单的功能。算法的合理利用不仅能增加正确率还能缩短开发周期
-
掌握了几种重要的开发模型，比如生产者消费者，观察者，工厂等。架构设计更加灵活多变。学会了使用input——handler，输入输出接口，工程目录结构
-
OO的思想初步掌握，可以合理地解耦每个对象的功能。了解并初步尝试了先测试后功能的思想，慢慢理解了可扩展结构的重要性，初步尝试了单元测试
-
不能高估自己写代码的速度，要尽早开始写，尽早完成，尽早测试。
课程改进建议：
-
课上测试环节真的难度太高。我觉得上午的课还没有来得及消化就要开始考试，甚至还要直接写代码实操，对于代码能力比较弱的同学就是难度非常高的事情。如果多放出来一些时间，让大家消化PPT上的内容，查一下资料，或者留一点思考问题，都是比较好的改进方法
-
个人觉得公告类消息的发布太随意了，刚刚上手的时候，一共有github,gitlab,oocourse讨论区,博客园，大班群，小班群这么多种通知方式。最重要的是，在一个平台上通知了，未必会在其他平台同步。由于一开始没能正确各个平台的功能，只关注gitlab，错过了一些重要节点（当然也怪一开始没能适应自主时间规划），希望下一次明确一个主通知方，并在开始时在通知群做一些提醒。
-
15分钟的冷却时间有点长。记得有一次是原来已经过了测评，但是发现了一个bug，当时还有30分钟，交上去的时候只有10多分钟了，结果把原来正确的改错了。（后来似乎被助教小哥哥捞了一把，但是也没进强测），要是最后2小时，5分钟交一次这个世界该有多么美好。
