《構建之法》第二章讀書筆記

2.1 單元測試

軟件是由多人合作完成的，不同人員的工作相互有依賴關系。例如，一個人寫的模塊被其他人寫得模塊調用。軟件的很多錯誤都來源於程序員對模塊功能的誤解、疏忽或不了解模塊的變化。如何能讓自己負責的模塊功能定義盡量明確，模塊內部的改變不會影響其他模塊，而且模塊的質量能得到穩定的、量化的保證？單元測試就是一個很有效的解決方法。

?2.1.1 用VSTS寫單元測試

?2.1.2 好的單元測試的標準

• 單元測試應該在最基本的功能/參數上驗證程序的正確性。
• 單元測試必須由最熟悉代碼的人（程序的作者）來寫。
• 單元測試過後，機器狀態保持不變。
• 單元測試要快（一個測試的運行時間是幾秒鐘，而不是幾分鐘）。
• 單元測試應該產生可重復、一致的結果。
• 獨立性——單元測試的運行/通過/失敗不依賴於別的測試，可以人為構造數據，以保持單元測試的獨立性。
• 單元測試應該覆蓋所有代碼路徑。
• 單元測試應該集成到自動測試的框架中。How？

• 單元測試必須和產品代碼一起保存和維護。

  ?2.1.3 回歸測試

  針對一個Bug Fix，我們也要做Regression Test。目的是：

1. 驗證新的代碼的確改正了缺陷
2. 同時要驗證新的代碼有沒有破壞模塊現有的功能，有沒有Regression

2.2 效能分析工具

兩種分析方法：

1. 抽樣
2. 代碼註入

如果我們不經分析就盲目優化，也許會事倍功半。

2.3 個人開發流程

1. 計劃
   *估計這個任務需要多少時間

2. 開發

   *分析需求

   *生成設計文檔

   *設計復審（和同事審核設計文檔）

   *代碼規範（為目前的開發制定合適的規範）

   *具體設計

   *具體編碼

   *代碼復審

   *測試（包括自測，修改代碼，提交修改）
3. 記錄用時
4. 測試報告
5. 計算工作量
6. 事後總結

7. 提出過程改進計劃

2.4 實踐

• 單一職責原則：一個模塊應該只有一個導致它變化的原因，一個模塊應該完全對某個功能負責。
• 開放-封閉原則：軟件實體應該是可以擴展的，同時是不可修改的。
• 簡單的程序從幾個維度逐步擴展，增加復雜度。

1. 從數據方面擴展
2. 從需求方面擴展
3. 從用戶方面擴展
4. 從軟件構件方面擴展

這章主要讓我認識到測試的重要性，現在我們主要是編寫代碼，並沒有考慮到代碼效率，執行時間等等問題，我記得在《從問題到程序》第四章筆者也談過這個問題，不過他是提供一個時間函數可以方便我們計算復雜度，其實測試的目的也在此，特別是對於團隊開發中各個模塊的測試，一個細小的改變可能就會大幅度提高效率。

2017-2018-1 20179215《構建之法》第二章