面向对象第十二次作业暨第三次博客作业
一、探究规格化设计
1.面向机器编程
从最初的打孔式编程到汇编语言，本质上都是对人很不友好的面向机器编程，尽管汇编语言相对于二进制编码有了更高的可读性，但是因为不直观、最简单的逻辑过程也要编程者一步步紧盯着，非常容易出错。
2.面向过程编程
面向过程是一次思想上的飞跃，将程序员从复杂的机器操作和运行的细节中解放出来，转而关注具体需要解决的问题。
3.软件危机
现在我们能借鉴的编程经验与约定俗成的习惯都是前人从经验与失败中总结出来的成功率更高的规律：
软件危机最典型的例子莫过于 IBM 的 System/360 的操作系统开发。佛瑞德·布鲁克斯(Frederick P. Brooks, Jr.)作为项目主管,率领 2000 多个程序员夜以继日的工作,共计花费了 5000 人一年的工作量,写出将 近 100 万行的源码,总共投入 5 亿美元,是美国的“曼哈顿”原子弹计划投入的 1/4。尽管投入如此巨大, 但项目进度却一再延迟,软件质量也得不到保障。布鲁克斯后来基于这个项目经验而总结的《人月神话》 一书,成了史上最畅销的软件工程书籍。
第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展,相比第一次软件危机主要 体现在“复杂性”,第二次软件危机主要体现在“可扩展性”、“可维护性”上面。传统的面向过程(包括 结构化程序设计)方法已经越来越不能适应快速多变的业务需求了,软件领域迫切希望找到新的银弹来解 决软件危机,在这种背景下,面向对象的思想开始流行起来。
4.规格化设计的诞生
规格化设计不是一次就完整的提出来的，一套完备有效的规格化设计标准也有一个发展的历程：1960年代晚期至1970年代晚期的期间中，编程语言的发展也有了重大的成果。大多数现在所使用的主要语言范式都是在这段期间中发明的。在1960年代以及1970年代中结构化程序设计的优点也带来许多的争议，特别是在程序开发的过程中完全不使用GOTO。[跑题]在正式上大学学习编程之前就听过一个关于GOTO的段子，在一部各种编程语言拟人化的漫画中，C语言在田径项目中由于使用GOTO语句在前半圈领先众人（众语言），在最有一个弯道直接跳到了未定义区域冲出了跑道GG。
1980年代的编程语言与之前相较显得更为强大。C++合并了面向对象以及系统程序设计。在语言设计上有个重大的新趋势，就是研究运用模块或大型组织化的程序单元来进行大型系统的开发。这一阶段程序的模块化、标准化程度进一步提高。
二、作业中关于规格的BUG
| 作业 | 分支名称 | 错误位置 | 问题原因 |
| 第九次作业 | JSF不符合规范 | Taxi.java | @和REQUIRE没有连在一起 |
| 第十次作业 | JSF不符合规范 | / | 因为想写成标准的英文不使用自然语言，部分EFFECTS留空，申诉后测试者认同我的想法撤回了BUG |
| 第十一次作业 | / | / | 经过三次重写，规格部分看起来好多了 |
三、分析BUG原因
在课程学习过程中我的问题主要出现在两个地方：
1.开始时规格书写不规范
第一次没有仔细看JSF说明犯了很多错误…感谢这次的测试者没有在JSF上大做文章，而是很实在地通过一个bug指出了我的问题并给出了一些建议。
2.使用了自然语言描述
第一次时使用了自然语言描述，在OO第五次课上实验后，因为提供的代码中有很多规范的JSF书写，所以才学会了该怎么写，但是此时EFFECTS部分我的理解还不对，很多地方留了空，并且理解错了OVERVIEW的功能，幸运的是测试者理解、接受了我的想法，没有在JSF上扣太多而是把测试和讨论重点放在了代码本身上；后来在第十一次作业我也尽快改正了以上的问题。
四、条件写法的改进
1. 使用自然语言描述
改进方法： 使用标准的符号语言描述逻辑关系
2. “@ REQUIRES”中间留有空格
改进方法： 改为： * @REQUIRES
3. 误认为返回值void类型的方法EFFECTS可以留空
改进方法： 像返回值为boolean类型的方法应有\result相关描述，void类型的方法的EFFECTS中如果不为null就将改变过涉及的类属性都写全；
4. 线程安全的方法规格不完备
改进方法：
*@THREAD_REQUIRES: locked(this);
*@THREAD_EFFECTS: locked(m);5. 再简单的方法也要写完善的JSF，侧面说明另一个问题
改进方法： 某次测试中我的被测有几个功能非常简单的方法，只有一行return，但是没有写JSF，侧面说明另一个问题就是各个方法之间功能性“不均衡”
五、分析聚集关系
| 作业 | 方法名 | BUG | 与JSF聚集关系 |
| 第九次作业 | / | Request有一些问题 | 加了不必要的线程锁，JSF冗余 |
| 第十次作业 | serve | 接单后没有暂停1s模拟上下车 | 主要是readme看漏了，JSF的EFFECTS部分也没有写全 |
| 第十次作业 | setLight | 在不合法路口设立红绿灯时没有给出输出提示 | / |
| 第十一次作业 | / | / | / |
六、归纳总结
因为陌生，所以会犯错；我比较幸运，遇到的测试者将测试重点放在功能上，只是在JSF部分指出我确实存在的问题没有把JSF当做刷分的工具。但是看到身边很多同学被扣很多很多JSF，我心里还是很难受的，教学团队为了让我们重视规格所以将之加入了互测，但是即使设置了扣分上限还是可能会受到不公正的待遇，每周四晚上十点点开oj就跟开奖一样，如果是两三个BUG，可以心平气和地把不合理的申诉了跟测试者聊聊天；要是一点开一片红，仔细一看还一大片JSF，可以洗洗睡了。平心而论我也因为互测好几次很生气，但是说实话没有想到更有效的让我们重视规格化的方法，老师一再强调这东西有时比代码本身更重要，但是就算设置个OO期末考试也不好测试这个，就当是把期末考试那种瞬间的紧张和难受分摊到平时了吧。如果可以提建议的话，我觉得OO第五次、第六次提供的代码中的JSF都写的非常不错，如果在第一次书写规格时就提供这些（标准的）代码作为参考的话，大家犯的错误可能会更少一些。
就我自己来说，通过这三次规格的撰写，对于如何介绍自己的函数、如何确保我的类和方法有效有了一定的掌握，但是在读了一些标准库的代码后觉得自己所写、所考虑的还有很多欠缺。