规格化设计的发展历史
(因为很难寻找，所以参考了下别的同学的调研结果)
规格化设计与结构化、模块化设计密不可分，伴随着OOP语言的发展，规格化设计思想逐渐形成体系，慢慢完善。
20世纪60年代，程序的模块化设计思想被提出。伴随着计算机行业的迅速发展，为了解决程序可靠性等问题，结构化、模块化的设计为程序员提供了使用接口。每个模块各司其职，这样的程序便于扩展和维护，大大降低了当时开发者的困难。
20世纪80年代，面向对象语言兴起，结构化、模块化的思想在面向对象语言里作用被体现得更加彻底。与此同时，为了提高程序语言的规范性，对类和方法进行更好的维护，对其进行规范化设计，也使得数据变得更加安全可控，测试也更加简单易行。
规格化设计为何受到重视
为了类和方法能够变得规范可控，对类和方法进行规范化要求就变得有必要起来。在工程里面， 一个程序也许会有多人同时进行编写，那么由于没人不同的代码习惯，可能产生不同的设计理念，通过规格化设计也可以同步多人的设计方法，避免产生设计上的漏洞。规格化的程序不更易于调试，也更容易被维护，有利于程序的长远生存和发展。
规格BUG表
仅homework9有规格bug，且无雷同问题(雷同的俩都被报了)
| Bug类别 | Bug内容 | 出现位置 | 代码行数 |
| 前置条件不为布尔表达式 | 用了逗号来连接而不是用&& | updateMap | 22 |
| 前置条件不为布尔表达式 | 用了逗号来连接而不是用&& | updateFlow | 4 |
规格BUG原因
究其原因是因为在写不等式时用了逗号，比如:0<=x1,x2<=1 这种类型，导致前置条件不是布尔表达式。但是很奇怪，在下一次作业里，助教又告诉我前置条件可以不为布尔表达式了，既然要这样子，我也没什么办法，起码从此以后我每次都有注意前置条件要为布尔表达式。
前置条件和后置条件的不好写法
(1)不用布尔表达式，而选择用自然语言
改进条件：use bool expression
(2)在后置条件里写出代码的算法实现
改进条件：only display the changes of attributes instead of the algorithm
(3)很多人喜欢在前置条件里写None，但我觉得这不是布尔表达式
改进条件: @REQUIRES: true
(4)过于简略，没有完整体现后置条件
改进条件: complete the effects
(5)用=代替==
改进条件: use ==
功能BUG
和规格BUG无聚集关系，一共就俩，就不列什么表了
第一次被报了3个都是因为整体算法偏慢，运行久了每个出租车就不同步了，然后就有问题了，为了解决这个问题，我让每个车sleep的时间变成了setTime-算法花费的时间。也就是给程序"造了个假",这样每辆车就同步了。
第二次是因为对于Load filename的指令忘记正则了，输个a|file.txt，程序也能正常执行，虽然我readme写了Load filename 由测试者来保证正确，但我也懒得管了。
心得体会
规格这个东西设置的初衷是好的，但拿来被恶意扣分就很可耻了。
有的人恶意扣了分后还站在制高点教育被测者，这就更不对了。
这种人我这么多周就遇到过一个，然后上次作业在吐槽版又看到了有同学恶意被扣，我也不知道是谁，但我只觉得，这很可悲。
在这种课程制度下，人性变得好可怕。