1【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
正例： MAX_STOCK_COUNT
反例： MAX_COUNT
2【強制】中括號是數組類型的一部分，數組定義如下：String[] args;
反例：請勿使用 String args[]的方式來定義
3【強制】POJO 類中的任何布爾類型的變量，都不要加 is，否則部分框架解析會引起序列化錯
誤。
4【強制】杜絕完全不規範的縮寫，避免望文不知義。 （回到第一條上同樣適用，應以表達明確爲目的，不要嫌名字暢 condition“縮寫”命名成
condi）
5【推薦】接口類中的方法和屬性不要加任何修飾符號（public 也不要加），保持代碼的簡潔
性，並加上有效的 javadoc 註釋。儘量不要在接口裏定義變量，如果一定要定義變量，肯定是
與接口方法相關，並且是整個應用的基礎常量。（之前一直從來沒有主要到這一點。要注意改進）
6.接口和實現類的命名有兩套規則：
1）【強制】對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務一定是接口，內部
的實現類用 Impl 的後綴與接口區別。 （這種模式不需要多說什麼大部分都應該按照此種模式執行，另外一種如果是形容能力的接口名稱，取對應的形容詞做接口名（通常是–able 的形
式）。
正例：AbstractTranslator 實現 Translatable）
7各層命名規約： 領域模型命名規約 4） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO（之前忘記是跟誰學的代碼風格，習慣定義爲POJO 實際上一般展示對象：xxxVO，xxx 一般爲網頁名稱。 ）
8【強制】不允許出現任何魔法值（即未經定義的常量）直接出現在代碼中。
反例： String key="Id#taobao_"+tradeId；
cache.put(key, value);
（這一點之前也從來不太注意到，一直以爲這樣書寫寫起來很方便，如果讀代碼邏輯時可以直接讀下去，其實這種方式可讀性更低，並且規範性特差）
9【強制】long 或者 Long 初始賦值時，必須使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，造成誤解。（這件事需要多加註意，之前並沒有太在意這件事情上面）
10 【推薦】不要使用一個常量類維護所有常量，應該按常量功能進行歸類，分開維護。如：緩存 相關的常量放在類：CacheConsts 下；系統配置相關的常量放在類：ConfigConsts 下。
說明：大而全的常量類，非得 ctrl+f 才定位到修改的常量，不利於理解，也不利於維護
11【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性默認值
12.【強制】構造方法裏面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
13.【強制】POJO 類必須寫 toString 方法。使用工具類 source> generate toString 時，如果繼
承了另一個 POJO 類，注意在前面加一下 super.toString。
說明：在方法執行拋出異常時，可以直接調用 POJO 的 toString()方法打印其屬性值，便於排
查問題。
14. 【推薦】使用索引訪問用 String 的 split 方法得到的數組時，需做最後一個分隔符後有無內 容的檢查，否則會有拋 IndexOutOfBoundsException 的風險。
15【推薦】循環體內，字符串的聯接方式，使用 StringBuilder 的 append 方法進行擴展 說明：反編譯出的字節碼文件顯示每次循環都會 new 出一個 StringBuilder 對象，然後進行
append 操作，最後通過 toString 方法返回 String 對象，造成內存資源浪費。
16【強制】使用工具類Arrays.asList()把數組轉換成集合時，不能使用其修改集合相關的方法，說明：asList 的返回對象是一個 Arrays 內部類，並沒有實現集合的修改方法。Arrays.asList
體現的是適配器模式，只是轉換接口，後臺的數據仍是數組。
17. 【強制】線程資源必須通過線程池提供，不允許在應用中自行顯式創建線程。
說明：使用線程池的好處是減少在創建和銷燬線程上所花的時間以及系統資源的開銷，解決資
源不足的問題。如果不使用線程池，有可能造成系統創建大量同類線程而導致消耗完內存或者
“過度切換”的問題
18【強制】多線程並行處理定時任務時，Timer 運行多個 TimeTask 時，只要其中之一沒有捕獲 拋出的異常，其它任務便會自動終止運行，使用 ScheduledExecutorService 則沒有這個問題。
19 【強制】線程池不允許使用 Executors 去創建，而是通過 ThreadPoolExecutor 的方式，這樣
的處理方式讓寫的同學更加明確線程池的運行規則，規避資源耗盡的風險。
說明：Executors 各個方法的弊端：
1）newFixedThreadPool 和 newSingleThreadExecutor:
主要問題是堆積的請求處理隊列可能會耗費非常大的內存，甚至 OOM。
2）newCachedThreadPool 和 newScheduledThreadPool:
主要問題是線程數最大數是 Integer.MAX_VALUE，可能會創建數量非常多的線程，甚至 OOM
20.【推薦】避免 Random 實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一 seed
導致的性能下降。
21【推薦】推薦儘量少用 else， if-else 的方式可以改寫成：
if(condition){ … return obj; } // 接着寫 else 的業務邏輯代碼; 說明：如果使用要 if-else if-else 方式表達邏輯，【強制】請勿超過 3 層，超過請使用狀態 設計模式。
22極有可能被循環調用的方法，不建議對參數進行校驗。但在方法說明裏必須註明外部參
數檢查。
23對大段代碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定代碼和非穩 定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分
異常類型，再做對應的異常處理。
24捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請
將該異常拋給它的調用者。最外層的業務使用者，必須處理異常，將其轉化爲用戶可以理解的
內容。
25不能在 finally 塊中使用 return，finally 塊中的 return 返回後方法結束執行，不 會再執行 try 塊中的 return 語句
26表名不使用複數名詞。
說明：表名應該僅僅表示表裏面的實體內容，不應該表示實體數量，對應於 DO 類名也是單數
形式，符合表達習慣
27varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，如果存儲長度
大於此值，定義字段類型爲 TEXT，獨立出來一張表，用主鍵來對應，避免影響其它字段索引
效率。
28超過三個表禁止 join。需要 join 的字段，數據類型保持絕對一致；多表關聯查詢時， 保證被關聯的字段需要有索引。