OO Summary Ⅲ

規格化設計的發展歷史

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