轉載地址：
file:///C:/Users/XQQ/Documents/Tencent%20Files/374797487/FileRecv/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C%E7%BB%88%E6%9E%81%E7%89%88v1.3.0.pdf
【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以 Test 結尾。
【強制】POJO 類中布爾類型的變量，都不要加 is，否則部分框架解析會引起序列化錯誤。
【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用單數形式，但是類名如果有複數含義，類名可以使用複數形式。
【推薦】如果模塊、接口、類、方法使用了設計模式，在命名時體現出具體模式。說明：將設計模式體現在名字中，有利於閱讀者快速理解架構設計理念。正例：
public class OrderFactory;
public class LoginProxy;public class ResourceObserver;
【推薦】接口類中的方法和屬性不要加任何修飾符號（public 也不要加），保持代碼的簡潔性，並加上有效的 Javadoc 註釋。儘量不要在接口裏定義變量，如果一定要定義變量，肯定是與接口方法相關，並且是整個應用的基礎常量。正例：接口方法簽名：void f(); 接口基礎常量表示：String COMPANY = "alibaba";反例：接口方法定義：public abstract void f();說明：JDK8 中接口允許有默認實現，那麼這個 default 方法，是對所有實現類都有價值的默認實現。
【參考】各層命名規約：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。
【推薦】不要使用一個常量類維護所有常量，按常量功能進行歸類，分開維護。說明：大而全的常量類，非得使用查找功能才能定位到修改的常量，不利於理解和維護。正例：緩存相關常量放在類 CacheConsts 下；系統配置相關常量放在類 ConfigConsts 下。
【推薦】如果變量值僅在一個範圍內變化，且帶有名稱之外的延伸屬性，定義爲枚舉類。下面正例中的數字就是延伸信息，表示星期幾。正例：public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6),SUNDAY(7);}
【強制】相同參數類型，相同業務含義，纔可以使用 Java 的可變參數，避免使用 Object。說明：可變參數必須放置在參數列表的最後。（提倡同學們儘量不用可變參數編程）正例：public User getUsers(String type, Integer... ids) {...}
【強制】外部正在調用或者二方庫依賴的接口，不允許修改方法簽名，避免對接口調用方產生影響。接口過時必須加@Deprecated 註解，並清晰地說明採用的新接口或者新服務是什麼。
【強制】Object 的 equals 方法容易拋空指針異常，應使用常量或確定有值的對象來調用equals。正例："test".equals(object);反例：object.equals("test");說明：推薦使用 java.util.Objects#equals（JDK7 引入的工具類）
【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性默認值。反例：POJO 類的 gmtCreate 默認值爲 new Date();但是這個屬性在數據提取時並沒有置入具體值，在更新其它字段時又附帶更新了此字段，導致創建時間被修改成當前時間。
【推薦】循環體內，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。說明：反編譯出的字節碼文件顯示每次循環都會 new 出一個 StringBuilder 對象，然後進行append 操作，最後通過 toString 方法返回 String 對象，造成內存資源浪費。反例：String str = "start";for (int i = 0; i < 100; i++) {str = str + "hello";}
【強制】泛型通配符來接收返回的數據，此寫法的泛型集合不能使用 add 方法，而不能使用 get 方法，做爲接口調用賦值時易出錯。說明：擴展說一下 PECS(Producer Extends Consumer Super)原則：第一、頻繁往外讀取內容的，適合用。第二、經常往裏插入的，適合用。
【強制】SimpleDateFormat 是線程不安全的類，一般不要定義爲 static 變量，如果定義爲static，必須加鎖，或者使用 DateUtils 工具類。正例：注意線程安全，使用 DateUtils。亦推薦如下處理：
private static final ThreadLocal df = new ThreadLocal() {
@Overrideprotected
DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
說明：如果是 JDK8 的應用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方給出的解釋：simple beautiful strongimmutable thread-safe。
【推薦】避免 Random 實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一seed 導致的性能下降。說明：Random 實例包括 java.util.Random 的實例或者 Math.random()的方式。正例：在 JDK7 之後，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要編碼保證每個線程持有一個實例。
【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，通過標記掃描，經常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。1） 待辦事宜（TODO）:（ 標記人，標記時間，[預計處理時間]）表示需要實現，但目前還未實現的功能。這實際上是一個 Javadoc 的標籤，目前的 Javadoc還沒有實現，但已經被廣泛使用。只能應用於類，接口和方法（因爲它是一個 Javadoc 標籤）。2） 錯誤，不能工作（FIXME）:（標記人，標記時間，[預計處理時間]）在註釋中用 FIXME 標記某代碼是錯誤的，而且不能工作，需要及時糾正的情況。
【強制】在使用正則表達式時，利用好其預編譯功能，可以有效加快正則匹配速度。說明：不要在方法體內定義：Pattern pattern = Pattern.compile(規則);
【推薦】及時清理不再使用的代碼段或配置信息。說明：對於垃圾代碼或過時配置，堅決清理乾淨，避免程序過度臃腫，代碼冗餘。正例：對於暫時被註釋掉，後續可能恢復使用的代碼片斷，在註釋代碼上方，統一規定使用三個斜槓(///)來說明註釋掉代碼的理由。
【強制】對大段代碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定代碼和非穩定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分異常類型，再做對應的異常處理。
【強制】finally 塊必須對資源對象、流對象進行關閉，有異常也要做 try-catch。說明：如果 JDK7 及以上，可以使用 try-with-resources 方式。
【強制】應用中不可直接使用日誌系統（Log4j、Logback）中的 API，而應依賴使用日誌框架SLF4J 中的 API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。import org.slf4j.Logger;import org.slf4j.LoggerFactory;private static final Logger logger = LoggerFactory.getLogger(Abc.class);
【強制】日誌文件推薦至少保存 15 天，因爲有些異常具備以“周”爲頻次發生的特點。
【強制】對 trace/debug/info 級別的日誌輸出，必須使用條件輸出形式或者使用佔位符的方式。說明：logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);如果日誌級別是 warn，上述日誌不會打印，但是會執行字符串拼接操作，如果 symbol 是對象，會執行 toString()方法，浪費了系統資源，執行了上述操作，最終日誌卻沒有打印。正例：（條件）if (logger.isDebugEnabled()) {logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);}正例：（佔位符）logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
【強制】好的單元測試必須遵守 AIR 原則。說明：單元測試在線上運行時，感覺像空氣（AIR）一樣並不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。 A：Automatic（自動化） I：Independent（獨立性） R：Repeatable（可重複）
【強制】單元測試應該是全自動執行的，並且非交互式的。測試框架通常是定期執行的，執行過程必須完全自動化纔有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。
【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint（ 1 表示是，0 表示否）。說明：任何字段如果爲非負數，必須是 unsigned。正例：表達邏輯刪除的字段名 is_deleted，1 表示刪除，0 表示未刪除。
【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，因爲無法進行預發佈，所以字段名稱需要慎重考慮。說明：MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。因此，數據庫名、表名、字段名，都不允許出現任何大寫字母，避免節外生枝。正例：aliyun_admin，rdc_config，level3_name反例：AliyunAdmin，rdcConfig，level_3_name
【推薦】字段允許適當冗餘，以提高查詢性能，但必須考慮數據一致。冗餘字段應遵循：1）不是頻繁修改的字段。2）不是 varchar 超長字段，更不能是 text 字段。正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。