「BUAA OO Unit 4 HW16」第四单元总结 —— 图书管理系统及课程总结

Part 1 本单元正向建模与开发实践

说实话，我最开始没理解什么叫做"正向建模与开发实践"。然后查了一下资料，注意到它是指在软件开发过程中，采用一种从需求到设计再到实现的顺序进行系统建模和开发的方法。那我就有点能理解了。

本单元的话，我是首先先对标指导书（也就是需求书）在草纸上对业务逻辑进行了梳理，图我还存着，在这里：

有了这图后我又规划了我将需要实现的类，每个类可能需要的属性，以及可能要有的方法，这个文件我也留有，如下：

然后我根据这个文字版的“类图”，初步画了一个UML类图，然后进行编码。在写的过程中还发现了一些我也需要用到的，但是却并没在这个类图草图中，所以在实现的时候又根据需要补充了一下最开始画的那个类图。纵观这整个过程，我觉得我基本做到了一个正向的建模，即先根据指导书进行一个设计，然后再根据自己的设计来指导自己正式进行编码。这种正向的实现过程，我觉得对减小我程序出bug的概率，降低我编码的难度以及提高我的架构的优雅度，都起到了比较好的作用。

Part 2 Unit 4 架构设计与相关分析

2.1 Unit4 架构设计

总结架构设计的话，我就拿第三次迭代后的成品代码来分析。一共是有21个类（是不是有点太多了？），分为几个大部分：1. 图书馆工作人员相关的类。 2. 学生类。 3. 图书系统类。 4. 工具类，比如：字符串解析类，日期处理类，输入处理类。

那么主要的业务运作流程就是：来一个请求，工具类，将该请求走一个switch来进行分派。需要哪个对象去处理这个请求，就分派给哪个对象（比如，来了一个借书命令，那么就需要将这个请求分派给Student，因为这个借书的操作是学生发出的，在Student Class中会有borrowBook方法）。分派过后，对应的对象对目标进行处理就ok了，一个类在处理的过程中，可能会与其他类交互，比如Student借书的时候要拿走图书馆的书，图书系统类就也要做相应的修改。

值得一提地是，我有在编写代码的时候主动地去向“高内聚，低耦合”的原则靠拢，编码时我有一种感觉就好像是：我写的A类是一个很大的大山，写的B类也是一个很大的大山，这两座大山之间，仅仅有一段很细的管道相连，他们两个之间仅仅由这个细小的管道接口联系起来，我觉得这个可以体现出一定的高内聚 低耦合的思想。这也让我的代码架构层次更加清晰分明，而不像u1一样非常地混乱。

2.2 代码设计与UML模型设计追踪关系

首先理解一下这个追踪关系，这个应该是指：我最后的实际代码设计和我最初的UML模型设计之间的关联和一致性。如果让我，给我这个最初的UML设计和实际代码设计的关联度进行打分的话，我觉得可以打到6分吧。没打更高是因为，我当初的UML设计中没有考虑到很多琐碎的小方法，这些都是后来又加上去的，没有打更低分是因为，关键的属性和方法我在最初的UML设计中还都是列出来了的，并参考其进行了实现，因此总体上来看，代码设计和UML设计之间的追踪性还是有一定的强度的。

Part 3 架构设计思维演进

1. 架构质量方面，刚开始的时候我自认为我写的代码是非常乱的。方法乱放，想到哪写哪，然后第二单元我就试图想要避免u1这种代码混乱的情况，然后我就去看了《大话设计模式》这本书，看了一些常见的设计模式，比如，工厂模式，单例模式以及生产者消费者模式。然后将这些设计模式初步运用到了我的代码中，取到了一定的效果。到了u4我在写的时候，就真地能明显地感觉到，我在编码时会主动去想办法降低耦合增强内聚了，我觉得这算是一个明显的进步与成长。

2. 架构意识方面，在刚开始的时候我其实就有在落实先设计再编码的原则了，因为这个原则在大二上学期的计组课上搭建cpu的时候已经略有实践了。比如第一单元的时候是先写了一个关键递归函数的伪代码，然后按照这个伪代码进行的实现。电梯也是先在草纸上设计好调度算法，然后再去实现…

Part 4 测试思维的演进

这个非常有的说，因为我是因为测试思维强测起飞过的人。
首先，说一下测试意识。

4.1 测试意识演变

hw1-hw5我觉得我的测试意识是不够的，经典的案例是hw5，当时我记得是周六下午过了中测，然后很开心，终于"写完了"嘛，甚至当天晚上还去看了校园歌手大赛的外场，第二天到了周日，我忘了当初是不是跑评测机发现的bug，总之就是发现了bug，但是紧改慢改，最后ddl的时候还是没改完，交了一个有bug的版本上去，中测当然过了，但是强测直接起飞。这就是说，我当初还没意识到，中测过了，远远不代表这次作业"写完了"，中测强测的强度会有很大差异，经历的那次作业的教训后我就深刻意识到了测试的重要性与必要性。至此后，基本每次作业都会尽量用评测机把程序跑穿了再去交中测，hw6自己写了个评测机，hw7迭代了hw6的评测机，hw9, hw10, hw11白嫖了同学们的评测机，自己改了改代码，给数据上了上强度来跑。hw13自己写了个五六百行的python评测机，hw14 hw15是数据限制有点多，加上考期压力，就自己捏了点数据跑了跑，倒是没怎么评测。测试意识非常重要，hw5及以前我的测试意识不够还比较低（当然hw3也自己写了评测机跑了跑，当时应该是时间比较多），扣的分数，比hw5之后所有作业加起来扣的分数还要多不少。

然后是测试方法。

4.2 测试方法演变

这个的话最开始hw1我就是随便找了点数据跑了跑就没管了，hw3应该是开始跑评测机了。之后的每次作业几乎都是用评测机的方式来评测的，当然，还会穿插一点所谓的“代码走查” 以及 手工捏数据的方法来测试，比如oktest方法，我就会在写好后再次对比JML一点一点地看代码看看有没有逻辑写错，以及由于oktest的测试数据不太好自动生成，所以我就尽量枚举各种情况地去手捏数据来测试。

Part 5 课程收获与建议

5.1 课程收获

1. 掌握了java语言的基本使用, 熟悉了强大的开发工具idea的使用。
2. 不仅学了java, 顺带学了python。为了写评测机而顺带学了点python, 感觉很有收获, 也时常和朋友调侃到oo课不仅要写个几百上千行的java程序, 还要写个几百行的python程序来验证java程序的正确性hh。
3. 学会了自动化测试, 之前上co的时候我是不会写评测机的, 但是在oo课中, 出于强测的压力, 算是被逼着自己去了解了python语法用它来写 自动评测机(数据生成器 + 正确性判定器/对拍器)
4. 提高了抗压能力, 对我而言, oo课是一个比较大的挑战, 有的时候作业写的甚至也有一点崩溃, 但好在最终坚持下来了, 心态也得到了磨练。
5. 了解了面向对象这个常用的编程思想，了解到了例如单例模式、工厂模式等设计模式。
6. 锻炼了工程能力，毕竟之前没写过上千行的代码(除了计组多次迭代后的cpu代码)
7. 代码风格，因为强制进行代码风格检查的要求，我的代码风格得到了很大的锻炼，现在写的代码比大一初学的时候可读性高了不少。

5.2 课程建议

1. 每单元第一次作业录制视频讲解指导书，比如：我们从0开始完成此次作业要做哪些事，来帮助快速上手。
2. 指导书尽量让一个其他单元的未参与编写指导书的助教学长自己看一遍，甚至可能的话做一遍，提出可能有的问题，然后去完善。
3. 先导课加上评测训练的内容（强调评测意识+讲解评测机搭建+甚至带学生动手搭评测机），哪怕稍微减少一些先导课作业的内容。
4. 互测，尽量给出数据不合法的理由，提高互测效率。
5. 中测上强度，不然容易给初学者“我的程序已经不错了”的错觉导致强测起飞。
6. 讨论区加入回复功能，而不是@线性回复。