讀代碼整潔之道有感

1. 代碼儘可能簡潔。
2. 函數參數儘可能少
3. 命名儘可能規範，動詞名詞儘可能合理專業術語命名少一些奇葩命名和變量命名
4. 抽離try catch 代碼塊

第五章 格式

5.1 垂直分佈 調用者函數方法應該儘可能在被調用者函數方法之上，挨着比較好。 注意縮進。

第六章 對象和數據結構

6.1 儘可能封裝對象傳參，

第七章 錯誤處理

7.1 上游try catch finally 下游throw 會使得代碼整潔，根據狀況而定 儘可能不讓null進入程序

第八章 邊界

8.1 集合儘可能使用泛型

8.2 使用API能夠多寫測試用例，方便新版本發佈的時候運行下看看新舊版本的差別作出更新，使用新API的能力。

8.3 善於利用橋接模式在不給API文檔的時候寫好接口，實現類能夠等給了接口寫。

第九章 單元測試

9.1 快速 獨立 可重複 自足驗證 及時

第十章 類

10.1 單一職責 內聚 對修改封閉，對添加開放

第十一章 系統

11.1 最好的集成方法是無侵入式集成，可插拔式集成。springaop切面就作的很好。 最好的系統就是代碼儘可能簡潔。

第十二章 跌進

12.1 單一職責很重要。 類儘可能小聚合，保持類方法儘可能少

第十三章 併發編程

13.1 對象是過程的抽象，線程是調度的抽象。

13.2 單一權責原則 分離併發和和其餘代碼； 限制數據做用域 如：synchronized關鍵字； 使用數據副本； 線程應儘量的獨立

13.3 線程執行模型：

13.4 鎖的使用：

警戒同步方法之間的依賴

13.5 保持同步區域微小

13.6 很難編寫正確的關閉代碼

第十四章 逐步改進

14.1 代碼整潔

代碼重構，在於一直更新本身很差的代碼趨向於本身認爲的完美。 時刻保持本身代碼的整潔。

第十五章 JUnit內幕

全部代碼都能重構的比以前更好，要推翻以前的不斷試錯，不斷更新才能更好。

第十六章 重構 SerialDate

代碼不合理的須要遷移。

第十七章 味道與啓發

17.1 註釋簡潔明瞭，沒用的註釋別寫，過時的刪除，多些一些代碼中沒有的可是須要注意的細節。

17.2 把多部才能實現的構建最好整成一歩，多步才能作到的測試整成一步。

17.3 函數 參數超過3個就須要考慮是否該改造方法了，最好是沒有參數的方法，輸出參數最好不要有，好比能夠用改對象的狀態來作替代，標識參數也很讓人迷惑，違反了單一職責原則，應當消滅它，死函數就要刪除，代碼管理工具能夠作找回。

17.4 通常性問題 一個文件中最好語言統1、不能忽視安全、避免重複、 抽象層級注意正確性、基類不能依賴於派生類、信息不能過多、死代碼記得刪除、垂直分隔關聯代碼少於100行代碼、先後一致、混淆視聽避免、人爲耦合注意、特性依賴不應有、選擇算子參數、晦澀的意圖須要註釋、位置放對地方、恰當的靜態方法、使用解釋性變量、函數名稱應該表達其行爲、理解算法、把邏輯依賴改成物理依賴、用多態替代if/else 或 switch/case、遵循標準約定、用命名常量替代魔法值、準確、結構甚於約定、封裝條件、避免否認性條件、函數只該作一件事、掩蔽時序耦合、別隨意、封裝邊界條件、函數應該只在一個抽象層級上、在較高層級放置可配置數據、避免傳遞瀏覽、合理使用通配符、不要集成常量、而是該導入常量類、採用描述性名稱、名稱應該與抽象層級相符、儘量使用標準命名法、無歧義的名稱、爲較大做用範圍選用較長名稱 、避免編碼、名稱應該說明反作用。

17.5 測試 別略太小測試、使用覆蓋率工具、被忽略的測試就是對不肯定事物的疑問、測試邊界條件、全面測試相近的條件、測試失敗的模式有啓發性、測試覆蓋率的模式有啓發性、測試應該快速。

附錄A 併發編程 II

死鎖：1. 互斥 2. 上鎖及等待 3. 無搶先機制 4. 循環等待

避免死鎖： 1. 不互斥 幾乎不可能，大多數資源都有上限 2. 不上鎖及等待，可能會引發線程飢餓或者活鎖。 3. 知足搶先機制，管理請求複雜。 4. 不作循環等待，若是獲取資源的順序和使用資源的順序不匹配也就沒法知足，或者沒法獲取資源順序那麼這個條件也沒法知足。