面向对象第四次总结性博客
面向对象第四次总结性博客
测试与正确性论证
这两次作业，我们分别体验了Junit单元测试和正确性论证。单元测试主要是从代码的实现结果出发，企图通过覆盖代码所有的代码分支和逻辑分支，来进行覆盖性测试。用穷举的办法进行覆盖测试是最简单的测试方式，特别是在有了Junit之后，测试变得有章法可循。但实际上，就算覆盖了所有的代码分支，也很难覆盖所有的逻辑分支。比如两条连续的if语句，实际上有4种组合方式，但实际上，只需构造一个样例，就能覆盖所有的代码分支，但逻辑分支只覆盖了一个。我在覆盖了所有的分支后，依然发现了一个小Bug。这就是Junit单元测试的不完备性。
正确性论证则是从规格出发，考虑代码的功能。先考虑逻辑，进而讨论该方法的功能是否正确实现。在正确性论证阶段，注意到吴际老师写的备注：“像数学归纳法的第...步”。正确性论证更能测试出代码的逻辑是否正确。但论证过程更加复杂，比如我的正确性论证就不小心写了30页。并且正确性论证也没有单元测试的结果那样直观。
OCL语言与JSF规格
OCL(Object Constraint Language)是对象约束语言，是对图形符号的补充，后来被正式规范为UML的一部分。他与JSF有很大的相似之处：
- 首先，他们都是无二义性的形式化语言
- 且都采用了前置条件和后置条件对方法的运行加以描述。
但是，二者的语法有着很大的不同。
- OCL语法更加高级，包括if-else语句等
- JSF仅有二阶逻辑结构，也没有对数据类型的描述等。
- OCL支持用context表达上下文，但JSF不支持上下文描述
- JSF中前置、后置条件与OCL的表述不同，OCL用pre,post表示
简而言之，JSF语言极大的轻量化了OCL语言。
GRAPH
UML
时序图
状态图
学期总结
模块之间的联系
第一模块：基础
Java基础学习，这部分的三个作业：多项式处理、单线程电梯、单线程可捎带电梯，实现难度依次上升，主要让我们熟悉了Java语法和课程的规则。为后面的学习和作业打下基础
第二模块：多线程
这部分的三个作业：多线程可捎带电梯，IFTTT，基础出租车也都是围绕多线程展开的。多线程是Java语言最大的特色，因此，怎样设计线程使得线程之间可以安全、高效地执行是这部分学习的目标。这部分承前启后，前乘可捎带单线程电梯，后启出租车系列作业，为本课程的重要衔接部分。同时，这部分也是难度最大的地方，初次接受多线程难免会出很多问题。
第三模块：规格化训练
虽然依旧是多线程出租车作业，但因为三次作业之间有着较大的关联，每次都要在上一次的基础上做功能的升级，所以，如何安排好代码各个部分之间的联系变得更重要。让自己的代码更符合规格，不仅有利于三次作业之间的承接关系，更能在互测时得到一个不错的分数。
第四部分：代码正确性检验与论证
因为在电梯作业部分大家都还没有过多注意自己的代码风格，所以在最后一个阶段反过来重构自己的代码，使代码在理论和测试方面都变得正确。重构代码更能让自己码力得到提升，特别是在学习了规格化设计之后。代码的规格化同时也降低了测试的困难程度，越规整的代码越容易测试，其逻辑性也强，便于论证正确性。
这四部分相辅相成，好的代码离不开码农自身的基本功，更离不开优秀的代码风格。课程将规格化训练和正确性论证的课时放得一样多，更意味着二者同等重要。在有好的代码实现的基础上，若在有着好的规格，更是锦上添花。
进步总结
课程一开始的时候，因为特别注重互测阶段的功能性，反倒冷落了风格。那时候喜欢把自己的思路一股脑得倾泻在代码上，写出来的代码也是面条式的。到了课程中后期，作业的设计让我们不得不考虑模块化的重要性，不然每次都要大篇幅重构代码。为了节省任务量，我也开始格外考虑将自己的代码尽可能模块化（虽然这样写JSF的时候有点难受）。
在第一次出租车作业中，我尽可能地用了面向对象的思维，将各个代码段的功能、逻辑等等拆分开，将每个方法的行数控制在50行内。紧接着就尝到了甜头，后三次的出租车只要稍加更改就可以完成任务。
再往后，到了正确性论证环节时，看着课程开始时写出的流水账电梯，虽然确实没有bug，但是真的丑哭。我想，对于我来说，可以把代码变得更加模块化，有着更强可读性，更多的使用继承和接口是我最大的进步。
工程化开发
我认为所谓的工程化，就是要让开发过程变得更加有规律，有章法可循。记得第一个工程化的过程是在计组里面，若不是没有高老板的那一套开发过程（打表格，分析转发暂停等等），能将所有的可能考虑清楚谈何容易。
在OO这门课中第二次经历了工程化，从开发人员角度，将代码做好封装，做好模块化，做好正确性的论证。这样在之后对代码的维护过程中只需要将一小部分功能做出升级即可，且只要做出更改的部分是“正确”的，那么整个代码依然可以保证正确性，极大得方便了开发过程。这也是我在OO的十多次作业中体会到的工程化。
工程化开发中必不可少的就是多人合作，虽然这次并没有相应的体会，但也得到了相应的训练。写好类规格、方法规格就是直接地方便了团队之间的合作。相信这一技能在以后的码代码生涯中能让我获益。
课程思考与建议
以下就从我的个人感受之间提两点点建议吧。
-
在多线程电梯和单线程电梯之间增加一次熟悉多线程的机会。
因为毕竟大家大部分都是第一次接触多线程，讲道理直接来电梯难度有点大，幸好有一个清明节假期作为过渡，不过时间依然紧张。如果能增加一次熟悉多线程的作业就好了。或者去掉IFTTT作业，然后增加一个简单的多线程电梯，比如多线程不可捎带电梯。 -
再压低JSF类bug的分值
其实出租车作业大家如果认真写都没有什么bug的，有的话大部分也是吹毛求疵找到的一些和issue或者哪个角落相违背的bug。这会导致有些同学找不到bug就用JSF来凑，明明是一个代码作业，却要被JSF扣好多，甚至有些同学采用了尽可能少写几个方法来减少JSF被扣可能性的极端方法。我觉得这部分分数应该再压低一点0.6分感觉再打个折差不多。
对于互测，虽然有问题，但是也想不到好的改进办法，就不提什么建议了。这个机制是好的，就是体验不怎么好，相信很多人会提出这方面的建议的。
这个课程真的虐啊，不过真的有收获，这半年可以说是我大学代码量最大的半年了。希望OO课可以在老师和助教的带领下越来越好。就酱~，最后一次作业收工！想想还有一点小不舍。
