《代碼整潔之道》筆記
第 1章 整潔代碼
1、閱讀本書有兩種原因：第一，你是個程序員；第二，你想成爲更好的程序員。很好。我們需要更好的程序員。
2、代碼寫的混亂影響項目進度。
3、整潔的代碼讀起來令人愉悅。
第 2章 有意義的命名
1、儘可能的使用標準命名方法，駝峯式命名
2、命名要找更有表現力的詞，看得懂的詞
3、類名和對象名應該是名詞或名詞短語，如 Customer，方法名應當是動詞或動詞短語，如 postPayment。
4、做有意義的區分
public static void copyChars( char a1[], char a2[]) {
for (int i = 0; i < a1. length; i + +) {
a2[ i] = a1[ i]; }
}
以數字系列命名（ a1、 a2，…… aN）是依義命名的對立面。這樣的名稱純屬誤導——完全沒有提供正確信息；
第 3章 函數
1、函數不該有 100行那麼長，20行封頂最好，不應該寫太長
2、最理想的參數是零參數，最長不要超過三個入參，儘量不要輸出參數
3、別返回或傳入null，或返回特殊對象
4、函數應該只做一件事，函數單一職責
- 函數名稱或者代碼塊的業務目標是什麼
- 函數的執行步驟，抽象層次是否相同
- 如果有足夠的行數在解決不相關的子問題，提取出來
- 每一行代碼是否在爲目標工作？如果不是，提取出來
5、使用異常代替直接返回錯誤碼，如下面代碼段。
- 可以使錯誤處理從主路徑中分離出來，使主流程清淅易懂
- 使用錯誤碼返回易導致深層次嵌套
try{
deletePage( page);
registry. deleteReference( page. name);
configKeys. deleteKey( page. name. makeKey());
} catch (Exception e) {
logger. log( e. getMessage());
}
6、提早返回可以減少嵌套並讓代碼整潔。
第 4章 註釋
別給糟糕的代碼加註釋——重新寫吧 —Brian W. Kernighan與 P. J. Plaugher
1、好的代碼比註釋更重要
2、註釋掉的代碼直接刪掉，可以在git上找到
3、在類級別使用Javadoc註釋來解釋所有部分如何工作
4、團隊版權及著作權聲明註釋
5、註釋應申明代碼高層次意圖，而非明顯細節
6、不要添加代碼的著作人信息，git可以乾的事情不要交給代碼
7、好代碼 > 壞代碼 + 好註釋
8、不準確的註釋要比沒註釋壞得多。它們滿口胡言。因爲代碼在變動，在演化。很不幸，註釋並不總是隨之變動——
第 5章 格式
1、選用一套管理代碼格式的簡單規則，然後貫徹這些規則。
2、變量聲明應儘可能靠近其使用位置。
3、實體變量應該在類的頂部聲明。
4、團隊認同一種格式風格，每個成員都應該採用那種風格。
5、我覺得IDea的自動格式化可行。
6、代碼行長度控制在100-120個字符
第 6章 對象和數據結構
1、將變量設置爲私有（ private），不想其他人依賴這些變量。
2、得墨忒耳律規定：方法不應調用由任何函數返回的對象的方法。
下列代碼違反了得墨忒耳律
final String outputDir = ctxt. getOptions()
. getScratchDir(). getAbsolutePath();
第 7章 錯誤處理
1、將try包含的代碼塊抽象成一個函數，使錯誤處理從主路徑中分離出來，使主流程清淅易懂。
2、執行 try-catch-finally語句中 try部分的代碼時，你是在表明可隨時取消執行，並在 catch語句中接續。
3、在方法中返回 null值是糟糕的做法，但將 null值傳遞給其他方法就更糟糕了。
第 8章 邊界
1、不要在生產代碼中試驗新東西，而是編寫測試來遍覽和理解第三方代碼。
2、學習性測試確保第三方程序包按照我們想要的方式工作。
一旦整合進來，就不能保證第三方代碼總與我們的需要兼容。
第 9章 單元測試
1、不要怕繁瑣，測試名字和方法應儘量詳細，測試代碼一樣需要整潔。
2、不要追求太高的測試覆蓋率，測試代碼前面90%通常比後面10%花的時間少
3、使用簡單的能夠完整運行的代碼測試輸入
4、測試代碼與生產代碼一樣重要，整潔的測試有三個要素：可讀性，可讀性和可讀性。
5、TDD三大定律，測試與生產代碼一起編寫，測試只比生產代碼早寫幾秒鐘。
定律一 在編寫不能通過的單元測試前，不可編寫生產代碼。
定律二 只可編寫剛好無法通過的單元測試，不能編譯也算不通過。
定律三 只可編寫剛好足以通過當前失敗測試的生產代碼。
6、敏捷和 TDD運動要求許多程序員編寫自動化單元測試。
7、JUnit中每個測試函數都應該有且只有一個斷言語句，斷言數量應該最小化。
@ Test
public void turnOnHeaterAndBlowerIfTooCold() throws Exception {
tooCold();
assertEquals(" HBchl", hw. getState());
}
第 10章 類
1、單一權責原則（ SRP）認爲，類或模塊應有且只有一條加以修改的理由。
2、系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權責，只有一個修改的原因，並與少數其他類一起協同達成期望的系統行爲。
3、依賴倒置原則（ Dependency Inversion Principle， DIP）。本質而言， DIP認爲類應當依賴於抽象而不是依賴於具體細節。
4、拓展，java類設計原則：
1依賴倒置原則
2里氏替換原則
3接口分隔原則
4單一職責原則
5開閉原則
6 迪米特法則（最少知道原則）
第 11章 系統
1、使用依賴注入實現分離對象的構造與使用，Spring框架提供了最有名的 Java DI容器。
2、使用spring AOP恢復橫貫式關注面模塊化。
第 12章 迭進（軟件設計層面）
創建具有良好設計的軟件的4條規則，優先級從高到低：
1、運行所有測試；（全面測試）
以下都屬於經過測試之後重構
2、不可重複；（極其雷同的代碼和實現的重複）
3、表達了程序員的意圖；（代碼後期維護）
4、儘可能減少類和方法的數量；（系統短小精悍）
以上規則按其重要程度排列。
第 13章 併發編程
“對象是過程的抽象。線程是調度的抽象。” ——James O Coplien
1、分離併發相關代碼與其他代碼。
2、採用 synchronized關鍵字在代碼中保護一塊使用共享對象的臨界區（ critical section）。限制臨界區的數量很重要。
3、謹記數據封裝；嚴格限制對可能被共享的數據的訪問。
4、嘗試將數據分解到可被獨立線程（可能在不同處理器上）操作的獨立子集。
5、採用 ConcurrentHashMap實現都比 HashMap表現得好，還支持同步併發讀寫，也擁有支持非線程安全的合成操作的方法。
6、生產者-消費者模型，讀者-作者模型，宴席哲學家。
7、避免使用一個共享對象的多個方法。
8、儘可能減小同步區域。
9、儘早考慮關閉問題，儘早令其工作正常。這會花費比你預期更多的時間。檢視既有算法，因爲這可能會比想象中難得多。
10、儘早並經常地在所有目標平臺上運行線程代碼。
第 14章 逐步改進
1、Args類逐步改進。
第 15章 JUnit內幕
1、重構是一種不停試錯的迭代過程，不可避免地集中於我們認爲是專業人員該做的事。
第 16章 重構 SerialDate
1、SerialDate是一個用 Java呈現一個日期的類。
第 17章 味道與啓發
1、關閉某些編譯器警告（或者全部警告！）可能有助於構建成功，但也存在陷於無窮無盡的調試的風險。
2、每個團隊都應遵循基於通用行業規範的一套編碼標準。
3、花時間明智地取名，保持名稱有關。名稱太重要了，不可隨意對待。
4、測試邊界條件。