面向对象课程第四单元博客总结
本单元架构总结
作业13架构：
作业14架构：
作业15架构：
架构思维演进
我的体验是四个单元的设置各有侧重：第一单元作为引导，树立起我们对于架构设计的初步印象；第二单元主要培养线程安全以及其背后的数据安全意识，并且包含进一步的架构思维建立；第三单元主要介绍形式化描述和验证的概念，培养对应的思维和能力，架构设计要求相对减弱；而第四单元类似架构设计“集成”的展现场所。
暂且除去已经给出架构的第三单元。第一单元其实通过研讨课、实验课，已经带领我们分析了因子、项、表达式的关系，几乎已经是提供给了我们设计架构的“参考答案”的；第二单元的架构设计主要是针对多线程安全问题的设计，主要任务在于考虑清楚线程行为，考虑好后架构就自然出来了；第四单元则像是练习场，没再给出过多的约束条件，需要由我们自行分析问题，设计架构。
听到有同学在第四单元说类很容易超500行或者方法很容易超80行，还需要再考虑哪些能分出去。我本人倒是感觉，如果一开始就遵循了SOLID原则，清晰划分好类的功能职责，其实不太会设计出冗长的类或方法来。可能也是得益于一直以来接受的架构思维培养。
测试思维演进
我觉得我是“慢热”的，或者说我的能力不足以让我“速热”。在第一单元，我还没建立起自动测试的意识，更别说形成完整的测试流程，起初验证思路只是对照指导书阅读代码梳理逻辑、头脑构造边界数据进行测试，结果正如我自己在第一单元博客里写的，我在第二次强测中就有数据点挂掉了，因为自己没想到那种情况——而靠头脑构造数据只能测出“没写对”的，怎么可能测出“没想到”的呢？第三次作业，我借鉴着别人讨论区发的帖，自己实现了一个简单的评测机。可以说节奏上赶得很狼狈，但效果至少是好的。
进入强度早有耳闻的第二单元，我和几个同学一起合作了评测机。每次有人负责迭代修改数据生成器，有人负责迭代修改检验程序，还有人负责跑对拍。不得不说，有几个人一起讨论数据生成确实能增强数据覆盖面，还更有效地实现了有针对性的多种模式数据生成，实现“既有大面积扫射又有定点爆破”。后来合作过的同学越来越多，我们统计每个人的性能作比较分析。但正如我博客写过的，我本人依然有翻车经历——在截至提交前改变策略，结果动了不该动的地方，正确性出问题了。从中吸取了很大教训。
到了相比之下轻松很多的三四单元，都是数据生成+对拍，我的测试流程和节奏也逐渐趋于稳定，也没再出什么意外。
课程收获
oo课程学习结束了，收获还是很多的。
-
提升码力。首先当然是在每周较大的作业任务量下，自己的代码能力得到了较大提升。
-
体会到架构思维的重要性。在一次次的作业中体会到，肯用较长的时间构思清楚架构设计，相对会在编码实现环节节约更多时间。
-
培养了测试思维。每单元的作业虽然在名义上只有作业，但完成作业-构思实现测试数据生成器-搭建简易评测系统其实已经成为标准流程。逐渐适应节奏后，我们不再会手忙脚乱于如何搭建评测机，而能够把重心转移到思考如何构造数据能覆盖更全面。
-
提高了合作能力。 虽然我知道很多同学是这样的，但 对我来说每周自己完整实现一套有一定测试强度的评测机工作量较大，特别是像第二单元，可能还需要多写几个策略，通过统计进行选择。所以我从第二单元开始，会和周围同学合作实现评测机、互相交流数据生成的思路和提出建议、大家一起做对拍并统计比较性能。据我所知这样的交流非常普遍，并且不是固定很死的小团体，竞争性不强且互相促进提高，我觉得这是非常有益的。
课程建议
-
希望尽量缩小公测和互测环节的数据范围差异。个人认为，在互测过程中阅读他人代码理解架构或是搭建评测机，这才是有所收获的环节，应该是可以用自己完成作业时注意到的坑点测试别人程序，而不是找到问题后还要费劲研究为什么数据不合法，或者愤愤不平别人能刀自己，自己却刀不了别人。
-
训练可以反馈成绩或者之后公布答案。我其实是没太get到训练不反馈结果的设计目的是什么，如果实时反馈评测结果难以实现或者不符合设计初衷，也可以考虑在一两天后公布成绩，或者至少发布参考答案？不然可能到最后也不知道自己的训练做的其实是错的，反而巩固了错误印象。
-
网站前端给作业介绍的界面加个目录导航吧。虽然还想提一些诸如调整pre布置时间、研讨课个人分享话题放开一点之类的想法，但最后一条还是留给这个——前端给作业介绍加个目录吧。
