规格化设计的发展历史

（这一部分并没有找到答案，于是参考了好黄和温莎莎的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不是用来被挂满分支树，那将毫无意义（无奈摊手）