【導讀】[開始]
"Clean Code（代碼整潔之道）"的全書閱讀對自己的啓發，以及工作過程中編程風格方面一些淺顯總結。不包含“併發編程”，“架構設計”這些方面的啓發，正在惡補“併發編程”這一塊知識，後面有進一步的認識時，再寫個總結。
【導讀】[結束]
命名的建議
- ①見名知意，名副其實。
- ②類名，對象名：多用名詞，名詞短語。
- ③方法名：動詞，動詞短語。
- ④對命名可添加適當的語境：如：addFirstName();addLastName();中First,Last等語境。
- ⑤不用雙關語：如Dao層，不用add()代替insert(),和update()二者的語義。而是建議用兩個語義明確的insert(),和update()方法。
- ⑥添加適當的前綴或是後綴，並保持一貫的統一風格。如接口，接口的實現類。有的喜歡對接口做前綴標識，有的喜歡對實現類做後綴標識，保持一貫的統一風格。
- ⑦每個概念對應於一個詞語，實質還是保持風格統一。如對方法命名,會遇到一些組裝對象的方法，有的喜歡對方法命名build*(),有的喜歡用assemble*(),保持一致語義風格，每個概念對應一個詞語，不要二者混用。
函數的建議
- ①一個函數應該只做一件事，做好一件事。
- ②函數的名稱：長而具有描述性的名稱，比短而令人費解的名稱好。
- ③函數入參：函數的入參儘可能少，不建議超過3個；如果參數過多，考慮封裝成對象作爲方法如入參。
- ④避免標識參數：儘量避免向函數傳入布爾值，作爲標識參數。
- ⑤函數避免副作用：函數的副作用是指函數在調用過程中，除了給出返回值外，還修改了函數外部對象的狀態，如調用過程中修改了某一個全局變量的狀態。
- ⑥錯誤處理：建議如果關鍵字try在某個函數中存在，它就該是函數的第一個單詞，而且在catch/finally代碼塊後面也不該有其它內容。
註釋的建議
- ①儘量少寫註釋（註釋不能美化糟糕的代碼( • ̀ω•́ )✧，顛覆了之前思想），前提是你能確保代碼的可閱讀性很好。
- ②必要的註釋有以下這些：
⑴法律信息，版權及著作聲明等
⑵提供信息的註釋，如註釋一些抽象方法的入參類型，返回值等
⑶闡釋，把某些晦澀難明的參數或返回值的意義翻譯爲某種可讀的形式。如StringUtils工具類中的，isBlank(),isEmpty()方法的註釋。
⑷警示信息。
⑸TODO註釋，TODO是一種認爲應該做，但由於某些原因目前還沒有做的工作。
異常處理###
- ①在編寫可能拋出異常的代碼時，最好先寫出try-catch-finally語句。
- ②受檢查異常違反了“開/閉原則”，建議在適當情況下，轉換爲“運行時異常”拋出。
- ③調用者，根據需要，對底層拋出的原始異常進行轉換後再拋出。
- ④不建議返回null值。如果打算在方法中返回null值，或是調用第三方API可能返回null值的方法。建議拋出異常，或是返回包裝後的特例對象進行替代。
- ⑤不建議傳遞null值。方法儘量避免傳遞null值。
###單元測試建議###
- ① 學習性測試是集成使用第三方API的快速方法。
- ②TDD(Test Driven Development)測試驅動開發
- ③ 整潔測試模式。把單元測試的過程拆分爲清晰的3步。構造-操作-檢查。第一個環節構造測試數據。第二個環節操作測試數據。第三個環節檢驗操作是否得到期望的結果。
- ④ 每個測試函數中只測試一個概念。
- ⑤ 整潔測試的"F.I.R.S.T原則"。
⑴快速(Fast),測試應該能夠快速運行。
⑵獨立(Independent)測試應該相互獨立。某個測試不應該成爲下一個測試設定的條件。
⑶可重複(Repeatable)，測試應該在任何環境中重複通過。
⑷自足驗證(Selt-Validating)，測試的成功失敗，最好輸出一個布爾值，便於直觀看到，而不是通過查看日誌文件來判斷是否通過。
⑸及時(Timely)，及時編寫單元測試。單元測試應該在成爲生產代碼之前編寫。
其它建議
- ① SOLID原則：
⑴SRP The Single Responsibility Principle 單一責任原則(每個類封裝一個權責，並與少數其它類一起協同完成功能。)
⑵OCP The Open Closed Principle 開放封閉原則
⑶LSP The Liskov Substitution Principle 里氏替換原則
⑷ISP The Interface Segregation Principle 接口分離原則
⑸DIP The Dependency Inversion Principle 依賴倒置原則(依賴抽象而不依賴具體，如繼承抽象類，實現接口，都是把較高層級的概念放到基類中，把較低層級的概念和實現細節放到派生類中；如依賴注入[DI]把對象的構造是使用進行分離。)
- ② AOP面向切面編程
⑴Java動態代理
⑵Spring AOP
⑶AspectJ
- ③ 代碼書寫位置，垂直分離的風格。
⑴變量和函數應該在靠近被使用的地方定義。
⑵本地變量（方法中定義的變量），應該正好在其首次被使用的位置上面聲明。垂直距離要短。
- ④ 恰當使用限制修飾符。不要爲子類創建大量受保護的變量和函數。通過控制限制信息來控制耦合度。
- ⑤ 恰當使用靜態方法。通常傾向於選用非靜態的方法。如果確定使用靜態方法，確保你不打算讓它有多態行爲。靜態方法無法多態。
- ⑥不要規避“時序耦合”。有必要使用時序耦合，而不是規避它。排列函數參數，好讓他們被調用的次序顯而易見。
eg:
Bad Coding:
public class MoogDiver{
Gradient gradient;
List<Spline> splines;
public void dive(String reason)
{
saturateGradient();
reticulateSplines();
diveForMoog(reason);
}
...
}
Good Coding:
public class MoogDiver{
Gradient gradient;
List<Spline> splines;
public void dive(String reason)
{
Gradient gradient=saturateGradient();
List<Spline> splines=reticulateSplines(gradient);
diveForMoog(splines,reason);
}
...
}