星期一, 1月 26, 2015

軟體建構之道:讀書心得(第三章-前期準備)

最近開始看了軟體工程的重量級書藉「軟體建構之道」,
來記錄下一些要點並助於知識吸收。

  1. 確認需求
    1. 在需求時期未解決的問題,到了建構時期,要花上很多倍的時間解決。
    2. 演進原型法:在建造系統前,先盡可能探索需求。
    3. 演進交付法:一次完成一點,從用戶獲得回饋,調整一點,再繼續建下一塊。
    4. 確定每個人都知道需求改變的代價。
    5. 建立一套需求改變的程序,例如審刻機制、變更時間點。
  2. 決定架構
    1. 在設計架構時期未解決的問題,到了建構時期,也必定要花上很多倍時間解決。
    2. 能對整個系統的類別做一個簡單綜述。
    3. 清楚每一個類的功能。
    4. 每一個需求都至少有一個類包覆。
    5. 定義核心類別、其它類別、類別之間的存取權限。
    6. 預測需求改變,預留變動空間,並將風險降至最小。也可運用延遲交付方法,將變動性的部份容後決定,例如把數據資料放在獨自的資源檔案中。
    7. 管理稀有資源。
    8. 性能評估。
    9. 可伸縮性。
    10. 安全性。
    11. 用戶界面模組化,利於替換。
    12. 錯誤處理:包含錯誤如何傳遞(立即丟棄/進入錯誤處理狀態/處理完才報錯)、錯誤如何記錄、錯誤何時處理(立即處理/順著function call上傳錯誤碼)由誰來處理錯誤(各類別各自處理/特定類別處理)、哪些層級以上資料必為正確、遇到錯誤如何處理(回到錯誤之前、使用替代函數、功能退化並自動重啟等)。錯誤處理一定要先規劃好,介面一致。
    13. 可行性:哪些是已被驗證可行的,哪些是有風險的。
    14. Overenginnering: 系統中哪些類別需要擁有較高健壯性?是可以做的比需求更好的?哪些類別不需要如此下功夫?系統中的類別是否都有考慮到健壯性?或者有的過頭了,有的做的不夠?
    15. 架構目標要清楚表述,並描述所有決策的機動。謹防「我們向來這樣做」。每個決定必有原因。並描述為什麼不使用別的方法?
    16. 架構擁有語言獨立性。
    17. 架構描述各個類別時,不要過頭,也不要缺少描述。
    18. 視圖:以不用視角來觀看架構,檢查錯誤。就像是室內設計的不同角度視圖一般。
  3. 後記:
    Data-driven: 利用if/switch來判別遇到什麼資料做什麼事。
    Table-driven:把所有資料放到array中,再利用迴圈進去分析資料。有助於將資料與程式碼隔離。

沒有留言: