單元測試

9.1 TDD三定律

• 在編寫不能通過的單元測試前，不可編寫生產代碼
• 只可編寫剛好無法通過的單元測試，不能編譯也不算通過
• 只可編寫剛好足以通過當前失敗測試的生產代碼

9.2 保持測試的整潔

測試代碼和生產代碼一樣重要。他需要被思考，設計和照料

9.3 整潔的測試

測試的要素：整潔性
** 9.3.1 面向特定領域的測試語言 **
面對特定領域的語言。不要直接使用程序員提供的對系統進行操作的API，而是打造一套包裝這些API的函數與工具代碼
** 9.3.2 雙重標準 **
有些事在生產環境中不能夠去做，而在測試環境中做卻完全沒有問題。

9.4 每個測試一個斷言

9.5 F.I.R.S.T

F:Fast,測試足夠快能夠快速運行
I：Independency，測試應該相互獨立，彼此沒有聯系
R：Repeatable，可以重復通過
S：Self-Validating，自足驗證
T：Timely，及時

第十章 類

10.1 類的組織
類應該由一組變量列表開始，如果有公共靜態變量，應該先出現，然后是私有靜態變量，以及私有實體變量，很少會有公共變量。
公共函數應該跟在變量列表之后。我們喜歡將某個公共函數調用的私有工具函數緊隨在該公共函數后面。
封裝
我們喜歡保持變量和工具函數的私有性，但并不執著于此。放松封裝總是下策。
10.2 類應該短小
類的大小的衡量，通過權責responsibility來判斷 。
類的名稱應該描述其權責，命名是判斷類的長度第一個手段，如果無法精確命名一個類，或者類名過長，很含混，該類越可能含有過多的權責。
10.2.1 單一職責原則
系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權責，只有一個修改的原因，并于少數其他類一起協同達成期望的系統行為。
10.2.2 內聚
類應該有少量實體變量。類中的每個方法都應該操作一個或多個變量。通常而言，方法操作的變量越多，就越黏聚在類上。如果一個類中的每個變量被每個方法所使用，則該類具有最大的內聚性。
10.2.3 保持內聚性會得到許多短小的類
當類喪失了內聚性，就拆分它。
10.3 為了修改而組織
對于大多數的系統，修改將一直持續。每處修改都讓我們冒著系統其他部分不能如預期般工作的風險。在整潔的環境中，我們對類加以組織，以降低修改的風險。
隔離修改
需求會改變，所以代碼也會改變。我們學習到，具體類包含實現細節，而抽象類只呈現概念。依賴于具體實現的客戶類，當細節改變時，就會有風險。我們可以借助與接口和抽象類來隔離這些細節帶來的影響。

第十一章 系統

11.1 如何建造一個城市
在較高的抽象層級---系統層級上保持代碼整潔。
11.2 將系統的構造和使用分開
軟件系統在起始過程中和起始過程之后的運行時邏輯分離開，在起始過程中構建應用對象，也會存在相互纏結的依賴關系。

=====