以下都是自己編寫代碼時候沒有遵守開發手冊的點，記錄下來，避免以後再犯
一、編碼規約
（一）命名風格
1、【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以Test 結尾。
2、【強制】POJO 類中布爾類型的變量，都不要加 is，否則部分框架解析會引起序列化錯誤。
這條我經常犯，比如變量是否存在，不能命名成 isExist
3、【參考】枚舉類名建議帶上 Enum 後綴，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。
說明：枚舉其實就是特殊的常量類，且構造方法被默認強制是私有。
正例：枚舉名字爲 ProcessStatusEnum 的成員名稱：SUCCESS / UNKOWN_REASON。
4、【參考】各層命名規約：
A) Service/DAO 層方法命名規約
1） 獲取單個對象的方法用 get 做前綴。
2） 獲取多個對象的方法用 list 做前綴。
3） 獲取統計值的方法用 count 做前綴。
4） 插入的方法用 save/insert 做前綴。
5） 刪除的方法用 remove/delete 做前綴。
6） 修改的方法用 update 做前綴。
B) 領域模型命名規約
1） 數據對象：xxxDO，xxx 即爲數據表名。
2） 數據傳輸對象：xxxDTO，xxx 爲業務領域相關的名稱。
3） 展示對象：xxxVO，xxx 一般爲網頁名稱。
4） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO。
簡單說從數據庫查出來的實體類用xxxDO，中間層代碼實體類用xxxDTO，前臺發送請求返回值的實體類用xxxVO
（二）常量定義
5、【強制】不允許任何魔法值（即未經定義的常量）直接出現在代碼中。
反例：String key = “Id#taobao_” + tradeId;
儘量把常量定義在最前邊，static final修飾，或者添加到枚舉或某個常量類中
6、 【推薦】常量的複用層次有五層：跨應用共享常量、應用內共享常量、子工程內共享常量、包 內共享常量、類內共享常量。
1） 跨應用共享常量：放置在二方庫中，通常是 client.jar 中的 constant 目錄下。
2） 應用內共享常量：放置在一方庫中，通常是 modules 中的 constant 目錄下。
反例：易懂變量也要統一定義成應用內共享常量，兩位攻城師在兩個類中分別定義了表示 “是”的變量：
類 A 中：public static final String YES = “yes”;
類 B 中：public static final String YES = “y”;
A.YES.equals(B.YES)，預期是 true，但實際返回爲 false，導致線上問題
3） 子工程內部共享常量：即在當前子工程的 constant 目錄下。
4） 包內共享常量：即在當前包下單獨的 constant 目錄下。
5） 類內共享常量：直接在類內部 private static final 定義。
7、【推薦】如果變量值僅在一個範圍內變化，且帶有名稱之外的延伸屬性，定義爲枚舉類。下面 正例中的數字就是延伸信息，表示星期幾。
正例：
public Enum {
MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);
}
（三）OOP約歸
8、【強制】Object 的 equals 方法容易拋空指針異常，應使用常量或確定有值的對象來調用 equals。
正例：“test”.equals(object);
反例：object.equals(“test”);
說明：推薦使用 java.util.Objects#equals（JDK7 引入的工具類）
寫任何一行代碼時候內心都要牢記是否非空，避免出現空指針異常這種低級錯誤
9、【強制】所有的相同類型的包裝類對象之間值的比較，全部使用 equals 方法比較。 說明：對於 Integer var = ? 在-128 至 127 範圍內的賦值，Integer 對象是在IntegerCache.cache 產生，會複用已有對象，這個區間內的 Integer 值可以直接使用==進行 判斷，但是這個區間之外的所有數據，都會在堆上產生，並不會複用已有對象，這是一個大坑， 推薦使用 equals 方法進行判斷。
其實，對於基本類型包裝類Integer，全部用.intValue方法轉爲int再用==比較就行了，這個地方我喫過大虧
10、【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具：source> generate toString 時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。
說明：在方法執行拋出異常時，可以直接調用 POJO 的 toString()方法打印其屬性值，便於排 查問題。
我就沒有這個習慣，爲了偷懶，以後要養成
11、【推薦】setter 方法中，參數名稱與類成員變量名稱一致，this.成員名 = 參數名。在 getter/setter 方法中，不要增加業務邏輯，增加排查問題的難度。
曾經就有原來的代碼把業務邏輯寫進了getter方法裏邊，我排查問題時找了半天也沒發現，當時根本就沒往那方面想
12、【推薦】循環體內，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。
說明：反編譯出的字節碼文件顯示每次循環都會 new 出一個 StringBuilder 對象，然後進行 append 操作，最後通過 toString 方法返回 String 對象，造成內存資源浪費。
反例：
String str = "start";
for (int i = 0; i < 100; i++) {
str = str + "hello";
}
這塊我之前不怎麼注意，總是直接用string拼串，顯得太low，以後要注意
（四）集合處理
13、【強制】關於 hashCode 和 equals 的處理，遵循如下規則：
1） 只要重寫 equals，就必須重寫 hashCode。
2） 因爲 Set 存儲的是不重複的對象，依據 hashCode 和 equals 進行判斷，所以 Set 存儲的 對象必須重寫這兩個方法。
3） 如果自定義對象做爲 Map 的鍵，那麼必須重寫 hashCode 和 equals。
說明：String 重寫了 hashCode 和 equals 方法，所以我們可以非常愉快地使用 String 對象 作爲 key 來使用
14、【強制】不要在 foreach 循環裏進行元素的 remove/add 操作。remove 元素請使用 Iterator 方式，如果併發操作，需要對 Iterator 對象加鎖。
這個就不用強調了，併發修改異常concurrentModificationException
15、【推薦】使用 entrySet 遍歷 Map 類集合 KV，而不是 keySet 方式進行遍歷。 說明：keySet 其實是遍歷了 2 次，一次是轉爲 Iterator 對象，另一次是從 hashMap 中取出 key 所對應的 value。而 entrySet 只是遍歷了一次就把 key 和 value 都放到了 entry 中，效 率更高。如果是 JDK8，使用 Map.foreach 方法。
這一點之前沒有注意過，貌似之前一直都是用的keySet方法
（五）併發處理
16、【強制】線程資源必須通過線程池提供，不允許在應用中自行顯式創建線程。
說明：使用線程池的好處是減少在創建和銷燬線程上所花的時間以及系統資源的開銷，解決資源不足的問題。如果不使用線程池，有可能造成系統創建大量同類線程而導致消耗完內存或者 “過度切換”的問題
17、【強制】線程池不允許使用 Executors 去創建，而是通過 ThreadPoolExecutor 的方式，這樣 的處理方式讓寫的同學更加明確線程池的運行規則，規避資源耗盡的風險。
說明：Executors 返回的線程池對象的弊端如下：
1）FixedThreadPool 和 SingleThreadPool: 允許的請求隊列長度爲 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。
2）CachedThreadPool 和 ScheduledThreadPool: 允許的創建線程數量爲 Integer.MAX_VALUE，可能會創建大量的線程，從而導致 OOM
emmmm…從來也沒用過ThreadPoolExecutor。。。。。。
（六）控制語句
18、 【推薦】除常用方法（如 getXxx/isXxx）等外，不要在條件判斷中執行其它複雜的語句，將復 雜邏輯判斷的結果賦值給一個有意義的布爾變量名，以提高可讀性。
說明：很多 if 語句內的邏輯相當複雜，閱讀者需要分析條件表達式的最終結果，才能明確什麼 樣的條件執行什麼樣的語句，那麼，如果閱讀者分析邏輯表達式錯誤呢？
正例：
// 僞代碼如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) { ... }
反例：
if ((file.open(fileName, "w") != null) && (...) || (...)) { ... }
（七）其他
19、 【強制】後臺輸送給頁面的變量必須加$!{var}——中間的感嘆號。
說明：如果 var=null 或者不存在，那麼${var}會直接顯示在頁面上。
原諒我孤陋寡聞，根本沒聽說過 $!{var}。。。。。。
二、異常日誌
20、【強制】對大段代碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定代碼和非穩 定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分 異常類型，再做對應的異常處理
未完待續。。。。。。