摘要
本文主要講解阿里JAVA開發手冊中比較重要的設計規範，這些重要的設計規範有助於我們改進自己的代碼，提升系統的系統的性能。
曾經與一位從阿里出來的Java工程師一起工作過一段時間，他的技術說不上非常厲害，但是，他的代碼寫的的非常好，凡是他做的功能很少出現Bug。我就很好奇，於是經常向他請教一些代碼設計的原則，然後他告訴了我阿里Java手冊。並且，他將這個手冊進行了修改，也成為了我司Java程序員的開發手冊。這篇文章就讓我們看一看這個手冊中比較重要的原則。
【強制】代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
反例：_name / __name / $name / name_ / name$ / name__
【強制】類型與中括號緊挨相連來表示數組。
正例：定義整形數組 int[] arrayDemo; 反例：在 main 參數中，使用 String args[]來定義。
【強制】POJO 類中布爾類型變量都不要加 is 前綴，否則部分框架解析會引起序列化錯誤。
說明：表達是與否的值採用 is_xxx 的命名方式，所以，需要在 設置從 is_xxx 到 xxx 的映射關係。
反例：定義為基本數據類型 Boolean isDeleted 的屬性，它的方法也是 isDeleted()，RPC 框架在反向解 析的時候，“誤以為”對應的屬性名稱是 deleted，導致屬性獲取不到，進而拋出異常。
【推薦】在常量與變量的命名時，表示類型的名詞放在詞尾，以提升辨識度。
正例:startTime / workQueue / nameList / TERMINATED_THREAD_COUNT
反例:startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD
【推薦】接口類中的方法和屬性不要加任何修飾符號(public 也不要加)，保持代碼的簡潔 性，並加上有效的 Javadoc 註釋。儘量不要在接口裡定義變量，如果一定要定義變量，肯定 是與接口方法相關，並且是整個應用的基礎常量。
正例:接口方法簽名 void commit();
接口基礎常量 String COMPANY = "alibaba";
反例:接口方法定義 public abstract void f();
說明:JDK8 中接口允許有默認實現，那麼這個 default 方法，是對所有實現類都有價值的默認實現。
【參考】枚舉類名帶上 Enum 後綴，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。
說明：枚舉其實就是特殊的類，域成員均為常量，且構造方法被默認強制是私有。
正例:枚舉名字為 ProcessStatusEnum 的成員名稱:SUCCESS / UNKNOWN_REASON。
【參考】各層命名規約:
- A) Service/DAO 層方法命名規約
1) 獲取單個對象的方法用 get 做前綴。
2) 獲取多個對象的方法用 list 做前綴，複數形式結尾如:listObjects。 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。
【強制】不允許任何魔法值(即未經預先定義的常量)直接出現在代碼中。
反例:String key = "Id#taobao_" + tradeId;
cache.put(key, value);
cache.put(key, value);
緩存 get 時，由於在代碼複製時，漏掉下劃線，導致緩存擊穿而出現問題
【強制】避免通過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增加編譯器解析 成本，直接用類名來訪問即可。
【強制】相同參數類型，相同業務含義，才可以使用Java的可變參數，避免使用Object。
說明：可變參數必須放置在參數列表的最後。(提倡同學們儘量不用可變參數編程)
正例：public List<user> listUsers(String type, Long... ids) {...}/<user>【強制】所有整型包裝類對象之間值的比較，全部使用equals方法比較。
說明：對於 Integer var = ? 在-128 至 127 範圍內的賦值，Integer 對象是在 IntegerCache.cache 產 生，會複用已有對象，這個區間內的 Integer 值可以直接使用==進行判斷，但是這個區間之外的所有數 據，都會在堆上產生，並不會複用已有對象，這是一個大坑，推薦使用 equals 方法進行判斷。
關於基本數據類型與包裝數據類型的使用標準如下:
- 1) 【強制】所有的 POJO 類屬性必須使用包裝數據類型。
- 2) 【強制】RPC 方法的返回值和參數必須使用包裝數據類型。 3) 【推薦】所有的局部變量使用基本數據類型。
說明：POJO 類屬性沒有初值是提醒使用者在需要使用時，必須自己顯式地進行賦值，任何 NPE 問題，或 者入庫檢查，都由使用者來保證。
正例：數據庫的查詢結果可能是 null，因為自動拆箱，用基本數據類型接收有 NPE 風險。
反例：比如顯示成交總額漲跌情況，即正負 x%，x 為基本數據類型，調用的 RPC 服務，調用不成功時， 返回的是默認值，頁面顯示為 0%，這是不合理的，應該顯示成中劃線。所以包裝數據類型的 null 值，能 夠表示額外的信息，如:遠程調用失敗，異常退出。
【強制】POJO 類必須寫 toString 方法。
使用 IDE 中的工具:source> generate toString 時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。
說明：在方法執行拋出異常時，可以直接調用 POJO 的 toString()方法打印其屬性值，便於排查問題。
【強制】關於hashCode和equals的處理，遵循如下規則：
- 1) 只要覆寫 equals，就必須覆寫 hashCode。
- 2) 因為 Set 存儲的是不重複的對象，依據 hashCode 和 equals 進行判斷，所以 Set 存儲的對象必須覆 寫這兩個方法。
- 3) 如果自定義對象作為 Map 的鍵，那麼必須覆寫 hashCode 和 equals。
說明：String 已覆寫 hashCode 和 equals 方法，所以我們可以愉快地使用 String 對象作為 key 來使用。
【強制】線程資源必須通過線程池提供，不允許在應用中自行顯式創建線程。
說明：線程池的好處是減少在創建和銷燬線程上所消耗的時間以及系統資源的開銷，解決資源不足的問 題。如果不使用線程池，有可能造成系統創建大量同類線程而導致消耗完內存或者“過度切換”的問題。
【強制】線程池不允許使用Executors去創建，而是通過ThreadPoolExecutor的方式，這樣的處理方式讓寫的同學更加明確線程池的運行規則，規避資源耗盡的風險。
總結
以上規範在設計代碼中，是比較重要的原則。如果編寫代碼的過程中，可以依照以上原則，那代碼的可讀性和可維護性將大大提升
閱讀更多 阿邁達聊技術 的文章
