OO第三次博客
3
//
首先，在开始写这篇博客之前，我突然想不起来这次作业是要回忆第几次作业了，这几周我对OO的热情已经归于0点，还有点负温了，自嘲一下，当初电梯的时候我还是第一个发issue的人（笑）。
规格化发展史
20世纪60年代，软件出现严重危机，Dijkstra提出了goto语句的危害，由此引发了软件界长达数年的论战，并产生了结构化程序设计方法。Pascal语言在20世纪70年代占有统治地位。
随着计算机技术的发展，结构化设计语言和结构化分析无法满足用户的需求，OOP由此应运而生，即面向对象的程序设计。OOP的诞生是程序设计方法学的一场革命，大大提高了开发效率，减少了软件开发的复杂性，提高了软件的可维护性，可拓展性。1990年以来，面向对象分析、测试、度量和管理研究都得到长足发展。
规格化设计伴随OOP而生，为了提高程序的规范性，对类、方法等进行规范化设计，有利于程序的模块化划分。这样设计程序的数据更加安全可控，测试也变得容易，软件的维护性得到提高，因而受到程序设计人员的重视。
bug列表
| bug类别 | bug内容 | 出现位置 |
| 抢单服务->无车响应不告知乘客 | 未在readme中说明如何使用修改边连通与否的指令 | readme |
| 抢单服务->抢单窗口大小不正确 | 同学你是没看答疑区吧，助教说了不能禁止指定出租车状态为服务或接单状态 | issue |
| 出租车运行一个时间不对 | 时间有误 | Timepasser.timepass |
| Effeccts逻辑错误 | 只写了充分条件，没写成充要条件 | TwoSideMessage.TwoSideMessage |
| JSF不符合规范 | 方法的jsf写在方法前面 | 心中 |
| 非法输入->无换行 | 没考虑到测试者违反指导书要求，不保证loadfile文件正确性时的情况 | LoadProcessor.startLoad |
bug产生原因
- 大家都比较想要分数。
- Timepasser循环时的时间粒度太大了。
- 交错readme了。
jsf不好的写法
前置条件
None
我的绝大多数函数的前置条件都是None，因为是private的，或者本身就是包内自用的，不过室友因此被报过incomplete，说太简短了，而且现在也还在仲裁ing，所以应该是不好的写法。
中文
犹豫了一下，因为我接手的所有测试代码，要么是None写法，要么是中文写法，所以既然None写法不好，中文写法应该是好的？但是中文不是JSF吧。
后置条件
把最终结果的=换成==，再利用替换移除中间变量
这是我写后置条件的方法，因为绝大多数函数都可以这么写，毕竟绝大多数函数的逻辑都很简单，只是很简单的状态访问罢了。不过因为容易忘记把=换成==，会被报bug，所以是不好的写法。
中文
中文不是JSF。
聚集关系
| 方法名 | 功能bug数 | 规格bug数 |
| readme | 1 | 0 |
| issue | 1 | 0 |
| Timepasser.timepass | 1 | 0 |
| TwoSideMessage.TwoSideMessage | 0 | 1 |
| 心中 | 0 | 1 |
| LoadProcessor.startLoad | 1 | 0 |
由表格中可以看出，功能bug和规格bug没有任何相关性。
基本思路和体会
规格是一种容易出错的东西，因为没有编译器会提示语法错误，也无法进行测试来检查正确性，所以在实际的工程实践中应该尽量避免使用规格。
给课程的话
这门课已经走歪了，我这样一个已经丧失热情的人的博客就不用看了，请老师看看那些认真对待这门课程的人这次写的博客，好好看看他们的bug到底都是怎样的bug——我们是学生，分数永远是第一驱动力，任何为了分数而努力的行为都是可以被称之为“学习”的行为。如果OO这门课并不是为分而学的话，那为何要引入排位制度？我们已经不是会为了虚荣、理想而奋斗的年纪了，都是实实在在、脚踏实地地一点一点地去扣的。
