(這一部分並無找到答案,因而參考了好黃和溫莎莎的blogs)java
1950年代,第一次分離,主程序和子程序的分離程序結構模型是樹狀模型,子程序可先於主程序編寫。經過使用庫函數來簡化編程,實現最初的代碼重用。產生基本的軟件開發過程:分析—設計—編碼—測試,使大型軟件系統的開發成爲可能編程
1975—1980年代,第二次分離,規格說明(Spec)和體(body)的分離說明是類型定義和操做描述,體是操做的具體實現。(具體的例子就是C++,Java等面嚮對象語言的類說明與類實現的分離。)解決方案設計只關注說明,實現時引用或者設計體。體的更改、置換不影響規格說明,保證了可移植性。支持多機系統,但要一樣環境。此時產生了劃時代的面向對象技術。安全
1995—2000年代,第三次分離,對象使用和對象實現的分離基於構件開發:標準化的軟件構件如同硬件IC,可插拔,使用者只用外特性,不計內部實現。Web Services:軟件就是服務。分佈式,跨平臺,鬆耦合。分佈式
大概就是有些方法(函數)代碼段會被屢次使用,而使用這些方法(函數)的人並不必定就是編寫的人,所以就須要用規格來告訴使用者這個方法(函數)須要保證的條件是哪些,以及會產生什麼影響,若是不對這些進行說明,調用者並不知道這個方法(函數)有哪些限制,調用就變得十分危險了。ide
除了爲了保證調用者可以安全使用方法(函數)外,規格也是幫助編寫方法(函數)者理清思路的利器(雖然我都是先寫的方法後補JSF),寫好規格理清了邏輯,就可以避免出現問題。函數
樹上開花了解一下~測試
出現這麼多規格類bug根本緣由仍是本身沒有體會到規格的重要性,以爲實際上是一種無關緊要的東西,因此也就沒認真寫也沒有很認真的看Guideline,也遇到了一個狠人r,被人挑了這麼多也沒話說……ui
(1) 使用天然語言編碼
(2) 對於一些模糊的問題不嚴格按照一種標準處理spa
(3) 過於簡略
(4) 沒有異常處理
(5) 各類筆誤
(1) 儘可能不要寫太長的方法,不然邏輯太複雜真的無法用布爾表達式來表示
(2) 這……只能本身注意了吧……畢竟看了別的代碼本身也沒有細究因此確實有些地方MODIFIES就寫了gui或者System.out,但有的方法就沒寫,人家給的理由就是:你到底以爲該不應寫呢?爲啥有的地方寫有的地方不寫?由於我菜啊QAQ…
(3) 儘可能用布爾表達式把全部的狀況都列舉出來吧。
(4) 補上補上。
(5) 本身菜不會用JSFtool嚶嚶嚶……結果就出現了「==」寫成「=」、\lock()寫成了\lock(s)這種……
(由於確實沒感受功能bug和規格bug有什麼關係因此就不混爲一談寫了……)
第九次:
PointBFS太慢了致使當輸入巨多請求的時候,哪怕開了額外的計算線程也算不完……
第十次:
加了紅綠燈之後出租車再也不同步致使流量不知道出了什麼問題,時不時回頭走一走……
第十一次:
(我以爲這不是功能性bug只是筆誤!!)
Main.java中在TAXI和VIP_TAXI轉化之間腦抽寫錯了條件,致使有的時候LOAD會出現問題,我的以爲這不是功能性bug不過既然被報了ERROR就先掛在這……
從實用性的角度來講:
仍是應該先寫好規格,把各個因素都考慮全面了,再開始寫代碼,而不是先寫程序回頭補規格。
從課程的角度來講:
(1) 你永遠叫不醒一個裝睡的人。
(2) 若是被測試者(我)的JSF不是用來被掛滿分支樹,那將毫無心義(無奈攤手)