規格化設計的發展歷史

（這一部分並沒有找到答案，於是參考了好黃和溫莎莎的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不是用來被掛滿分支樹，那將毫無意義（無奈攤手）

OO Summary Ⅲ