规格化设计的发展历史
（这一部分并没有找到答案，于是参考了好黄和温莎莎的blogs）
1950年代，第一次分离，主程序和子程序的分离程序结构模型是树状模型，子程序可先于主程序编写。通过使用库函数来简化编程，实现最初的代码重用。产生基本的软件开发过程：分析—设计—编码—测试，使大型软件系统的开发成为可能
1975—1980年代，第二次分离，规格说明（Spec）和体（body）的分离说明是类型定义和操作描述，体是操作的具体实现。（具体的例子就是C++,Java等面向对象语言的类说明与类实现的分离。）解决方案设计只关注说明，实现时引用或者设计体。体的更改、置换不影响规格说明，保证了可移植性。支持多机系统，但要同样环境。此时产生了划时代的面向对象技术。
1995—2000年代，第三次分离，对象使用和对象实现的分离基于构件开发：标准化的软件构件如同硬件IC，可插拔，使用者只用外特性，不计内部实现。Web Services：软件就是服务。分布式，跨平台，松耦合。
规格化设计为何得到大家的重视
大概就是有些方法（函数）代码段会被多次使用，而使用这些方法（函数）的人并不一定就是编写的人，因此就需要用规格来告诉使用者这个方法（函数）需要保证的条件是哪些，以及会产生什么影响，如果不对这些进行说明，调用者并不知道这个方法（函数）有哪些限制，调用就变得十分危险了。
除了为了保证调用者能够安全使用方法（函数）外，规格也是帮助编写方法（函数）者理清思路的利器（虽然我都是先写的方法后补JSF），写好规格理清了逻辑，就能够避免出现问题。
被报告的规格bug
树上开花了解一下~
出现这么多规格类bug根本原因还是自己没有体会到规格的重要性，觉得其实是一种可有可无的东西，所以也就没认真写也没有很认真的看Guideline，也遇到了一个狠人r，被人挑了这么多也没话说……
JSF不好的写法
(1) 使用自然语言
(2) 对于一些模糊的问题不严格按照一种标准处理
(3) 过于简略
(4) 没有异常处理
(5) 各种笔误
改进措施
(1) 尽量不要写太长的方法，否则逻辑太复杂真的没法用布尔表达式来表示
(2) 这……只能自己注意了吧……毕竟看了别的代码自己也没有细究所以确实有些地方MODIFIES就写了gui或者System.out，但有的方法就没写，人家给的理由就是：你到底觉得该不该写呢？为啥有的地方写有的地方不写？因为我菜啊QAQ…
(3) 尽量用布尔表达式把所有的情况都列举出来吧。
(4) 补上补上。
(5) 自己菜不会用JSFtool嘤嘤嘤……结果就出现了“==”写成“=”、lock()写成了lock(s)这种……
功能bug
（因为确实没感觉功能bug和规格bug有什么关系所以就不混为一谈写了……）
第九次：
PointBFS太慢了导致当输入巨多请求的时候，哪怕开了额外的计算线程也算不完……
第十次：
加了红绿灯以后出租车不再同步导致流量不知道出了什么问题，时不时回头走一走……
第十一次：
（我觉得这不是功能性bug只是笔误！！）
Main.java中在TAXI和VIP_TAXI转化之间脑抽写错了条件，导致有的时候LOAD会出现问题，个人觉得这不是功能性bug不过既然被报了ERROR就先挂在这……
心得体会
从实用性的角度来说：
还是应该先写好规格，把各个因素都考虑全面了，再开始写代码，而不是先写程序回头补规格。
从课程的角度来说：
(1) 你永远叫不醒一个装睡的人。
(2) 如果被测试者（我）的JSF不是用来被挂满分支树，那将毫无意义（无奈摊手）