規格化設計的發展曆史
（這一部分由于未能在網上找到較為準确的資料，是以參考了另一篇部落格https://www.cnblogs.com/buaazzw/p/9099526.html）
1950年代，第一次分離，主程式與子程式的分離結構是樹狀模型，子程式可先于主程式編寫。通過使用庫函數來簡化程式設計，實作最初的代碼重用。産生基本的軟體開發過程：分析—設計—編碼—測試，使大型軟體系統的開發成為可能。
1975—1980年代，第二次分離，規格說明（Spec）和體（body）的分離說明是類型定義和操作描述，體是操作的具體實作。（具體的例子就是C++,Java等面向對象語言的類說明與類實作的分離。）解決方案設計隻關注說明，實作時引用或者設計體。體的更改、置換不影響規格說明，保證了可移植性。支援多機系統，但要同樣環境。此時産生了劃時代的面向對象技術。
1995—2000年代，第三次分離，對象使用和對象實作的分離基于構件開發：标準化的軟體構件如同硬體IC，可插拔，使用者隻用外特性，不計内部實作。Web Services：軟體就是服務。分布式，跨平台，松耦合。
規格化設計為何得到大家的重視
因為在程式編寫過程中，一些代碼段會被多次使用，而這些常用的代碼段可能會由編寫者編寫封裝成方法或函數後分享給其他程式設計者使用，是以就需要通過規格告知使用者這個方法的作用以及需要保證的條件有哪些，讓使用者能正确有效地使用這些代碼段。
除了為了保證使用者可以正确有效地使用這些方法外，規格也是幫助編寫者理清思路的工具，在明确了一個方法的作用以及需求之後，可以便于編寫者理清邏輯，可以更高效地編寫程式。
被報告的規格bug
JSF整體：格式錯誤，沒加@或者未使用正确的注釋格式。
REQUIRES:需求限制不夠嚴謹。
MODIFIES:需要注明this的地方寫了無。
JSF不好的寫法
（1）使用自然語言
（2）過于簡略
（3）沒有異常處理
（4）出現錯誤符号
（5）對于一些問題的處理模糊
改進措施
（1）減小方法的代碼長度，避免使用過長的布爾表達式
（2）盡量考慮到所有可能情況
（3）加上異常處理
（4）認真仔細
（5）咨詢他人或查詢資料
功能bug：
第九次：
代碼未被測試。
第十次：
由于代碼執行時間的問題，流量重新整理與流量增加并未同步，造成計程車不遵循流量的情況。
第十一次：
心得體會
寫代碼的時候應該先考慮規格，考慮周全之後再開始編寫代碼，否則回頭補充規格容易出現疏漏。多線程執行時，對于多線程同步的問題還需要仔細研究學習。