规格设计的发展历史
在20世纪60年代，软件设计出现危机，例如 Dijkstra 提出了 goto 语句的种种危害，引发了软件开发领域的长期的论战。在这时间产生了结构化程序设计方法，例如Pascal语言在70年代占有统治地位。
之后，随着计算机软件规模日渐庞大，结构化程序设计方法无法满足用户的需求，面向对象程序设计方法(OOP)应运而生。面向对象程序设计是一场重大的革命，提高了开发人员的效率，有效的控制了软件开发的复杂度，提高了软件的可维护性和可拓展性。（但是牺牲了软件运行的效率）
规格化设计是随着面向对象程序设计的火热而发展起来的，可以有效提高程序的规范性以及程序的模块化划分，使得程序数据更加安全，软件的可维护性得到提高。
至于我们使用的JSF，只是一种不成气候的教学用规格，可读性和书写性都很差。
规格 bug
最开始构造方法没写规格，被报了一个。
后来被人说要用==不能用=，被报了两个。
剩下的都是自然语言，自然语言为所欲为。
规格 bug 产生的原因
测试者钻牛角尖，咬文嚼字，吹毛求疵。
JSF的规定陈腐破败，难以捉摸，需要完善。
自己写的程序方法稍长，面向过程，没法规格。
以及测试者只看语法，不看内容，只求扣分，不求理解方法内容。OO课程前后衔接不当，修改代码体系工程庞大，无法实现规格化的转变。
分别列举 5 个前置条件和 5 个后置条件的不好写法, 并给出改进
前置条件
我的前置条件没有用过自然语言，也没有被扣过分，硬要我找出哪里写的不好也很困难，因为我觉得自己写的挺好的。
不过也只能硬着头皮找一找。
- run方法没有写前置条件。
- 有几个设计到synchronized的方法没写线程的前置条件。
- 有几个前置条件用分号连接了，改成&&即可。
- 有几个前置条件写的是NONE，应改成None。
- 规定点坐标范围时不应写p.in(range(...))这种，应该x,y分开写。
后置条件
- 没有写捕捉到异常要怎么做。
- 用&&连接而不是分号连接。
- =改成==。
- 不能用到过程中的变量。变成其他表达式。
- 自然语言书写的, 应改为 JSF 标准格式
功能 bug 与规格 bug 在方法上的聚类关系
没有功能BUG。
规格BUG只有格式错误。
先写的功能后写的规格，逻辑上讲不会有聚类关系。
设计规格和撰写规格的基本思路和体会
首先问写设计规格有没有用？答：有用，这样便于维护开发。
其次问OO课写设计规格有没有用？答：有用，因为多次作业之间需要相互继承，需要规格来维护程序。
再次问规格有统一的格式有没有必要？答：有必要，因为假如不同人写的规格不一样，可能会造成歧义，导致开发出现问题。
再其次问OO课写统一的设计规格有没有必要？答：没有必要，因为OO课写的代码只有自己会维护。适合自己的才是最好的，规格怎么写不应有统一的标注。
再再次问OO课的规格好不好？答：不好。按照OO课的要求写出来的规格，往往看了规格也不知道方法要做什么，类要做什么。写了等于没写，不如自然语言写几行注释。
再再其次问在OO课写规格是否让我学到了什么技能？答：一丁点也没有。因为只想着怎么避免格式上被扣分，内容上完全不会考虑，反正测试者也基本不会读代码，看你的规格和代码是否一致。
总结：写设计规格是好的，但是写无意义的设计规格是不好的；OO课学设计规格是好的，但是OO课检查设计规格的过程是坏的；有统一的设计规格标准是好的，但是现有的规格的可读性是很糟糕的。