如何 減少 寫程式 的 風險，作出 較精確的 時程估計

記錄一下實作時的想法

一開始，是一片混亂，不知道從哪邊開始著手
不確定這兩個研究是否還可以順利操作
不知道如何規畫時間，不知道兩周是否能完成

之前在 Head First OOAD 書上提到 減少風險 的想法
最大的風險來自無知，要減少風險就是要 減少不確定的因素
那麼就先來設計程式的流程吧

1. Top-down 設計程式流程：

設計出 來源 –> 目標 的 overview flow (如左圖)
來確定每一個 function block (藍色方塊) 的 輸入 / 輸出 是什麼?
大致的想好 function block 的可行性
如果有需要 再為 function block 畫出其流程圖 (如右圖)
(function block 要到多細? 個人的感覺是，可以很快的想出其 pseudo code 時，就差不多了)

先設計程式的流程，有幾個好處

• 對程式流程有大概的了解，了解問題有多嚴重? XD
• 提早發現不確定的地方，不可行的地方，需要其他支援/技術的地方
• 實作時不會迷失方向，能設計出較好的介面
• 可以較精確的估計時程，這是最重要的，減少不確定性，才能作出合理的預估

2. 開始寫程式，要從什麼開始寫?
秉持著 減少風險 –> 減少不確定的因素 的想法
我選擇從 頭尾的 block (Fetcher / Inserter) 開始寫，
因為這兩個是對外的介面，完成對外的介面，剩下的都是在自已可以掌控的範圍內，相較之下風險較小

先寫出所有對外的介面，有什麼好處：

• 優先解決不確定的因素，剩下可以完全自已掌控的環境
• 隔絕外界的干擾，讓你的程式可以與外界更獨立的運作，就算面對的外在環境改變，就只用改介面部份的程式就好

3. 寫程式的過程中，使用 unit test / recorded test
為什麼要寫 unit test? 以及 什麼是 unit test? 可以參考 fcamel 大大 所寫的文章 為什麼要寫 unit test? 為什麼要先寫測試?
概念就是，為你的程式的每一個 function (unit)，寫測試，而且最好要先寫
寫測試的效果大家都知道，就是確保你的程式的正確性
除此避免 bug 外，它也是一種減少風險的方法

• 避免過度設計 (over-design)：先寫測試，可以讓你了解 function 的輸入 和 輸出，只用寫出滿足輸入 / 輸出正確就行了，往往 “這功能以後很可能會用到" 的寫出來的功能，多半都是用不到。更何況，要用到，以後再寫就好。
• 提高程式的可讀性 (readability)：程式常常無法重新利用的原因，都是看不懂它在幹嘛 或是 跑出來的結果跟想像不一樣。測試 就 是許多的 use case，可以很快的幫助了解程式。
• 提高程式的重用性 (re-usability)：當一個 function 覺得難以測試時，就代表它該被拆成多個小 function。例如: 要寫一個 function 來以 統計 文件中 各個字 出現的數量，字以空白就分隔。這當然可以寫成一個 function 來解決，只是這測試起滿麻煩的；較好的寫法是，拆成3個 functions，一個讀入檔案，一個切空白，一個統計次數。如此一來 各 function 的定位簡單易懂，如此也提高了重用性，假設之後要 以 tab 作分隔 或是 算出文章的長度，都只用再改一個 function 就好了