目錄
一、 程式設計規約
(一) 命名風格
(二) 常量定義
(三) 代碼格式
(四) OOP規約
(五) 集合處理
(六) 并發處理
(七) 控制語句
(八) 注釋規約
(九) 其它
二、異常日志
(一) 異常處理
(二) 日志規約
三、單元測試
四、安全規約
五、MySQL 資料庫
(一) 建表規約
(二) 索引規約
(三) SQL語句
(四) ORM映射
六、工程結構
(一) 應用分層
(二) 二方庫依賴
(三) 伺服器
七、設計規約
【強制】代碼中的命名均不能以下劃線或美元符号開始，也不能以下劃線或美元符号結束。
反例:_name / __name / $name / name_ / name$ / name__
【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。說明:正确的英文拼寫和文法可以讓閱讀者易于了解，避免歧義。注意，純拼音命名方式更要避免采用。
正例:renminbi / alibaba / taobao / youku / hangzhou 等國際通用的名稱，可視同英文。
反例:DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變量 = 3
【強制】類名使用UpperCamelCase風格，但以下情形例外:DO/BO/DTO/VO/AO/ PO / UID 等。
正例:JavaServerlessPlatform / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例:javaserverlessplatform / UserDo / XMLService / TCPUDPDeal / TAPromotion
【強制】方法名、參數名、成員變量、局部變量都統一使用lowerCamelCase風格，必須遵
從駝峰形式。
正例: localValue / getHttpMessage() / inputUserId
【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字
長。
正例:MAX_STOCK_COUNT / CACHE_EXPIRED_TIME
反例:MAX_COUNT / EXPIRED_TIME
【強制】抽象類命名使用Abstract或Base開頭;異常類命名使用Exception結尾;測試類命名以它要測試的類的名稱開始，以 Test 結尾。
【強制】類型與中括号緊挨相連來表示數組。
正例:定義整形數組 int[] arrayDemo;
反例:在 main 參數中，使用 String args[]來定義。
【強制】POJO類中布爾類型變量都不要加is字首，否則部分架構解析會引起序列化錯誤。說明：在本文MySQL規約中的建表約定第一條，表達是與否的值采用is_xxx的命名方式，是以，需要在 <resultMap>設定從is_xxx到xxx的映射關系。
反例：定義為基本資料類型Boolean isDeleted的屬性，它的方法也是isDeletedO，RPC架構在反向解 析的時候，"誤以為"對應的屬性名稱是deleted，導緻屬性擷取不到，進而抛出異常。
【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用單數形式，但是類名如果有複數含義，類名可以使用複數形式。
正例:應用工具類包名為 com.alibaba.ai.util、類名為 MessageUtils(此規則參考 spring 的架構結構)
【強制】避免在子父類的成員變量之間、或者不同代碼塊的局部變量之間采用完全相同的命名，使可讀性降低。說明:子類、父類成員變量名相同，即使是 public 類型的變量也是能夠通過編譯，而局部變量在同一方法内的不同代碼塊中同名也是合法的，但是要避免使用。對于非 setter/getter 的參數名稱也要避免與成員變量名稱相同。
反例:
【強制】杜絕完全不規範的縮寫，避免望文不知義。
反例:AbstractClass“縮寫”命名成 AbsClass;condition“縮寫”命名成 condi，此類随意縮寫嚴重
降低了代碼的可閱讀性。
【推薦】為了達到代碼自解釋的目标，任何自定義程式設計元素在命名時，使用盡量完整的單詞組合來表達其意。
【推薦】在常量與變量的命名時，表示類型的名詞放在詞尾，以提升辨識度。
正例：startTime/ workQueue / nameList / TERMINATED_THREAD_COUNT
反例：startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD
【推薦】如果子產品、接口、類、方法使用了設計模式，在命名時需展現出具體模式。說明:将設計模式展現在名字中，有利于閱讀者快速了解架構設計理念。
正例: public class OrderFactory; public class LoginProxy; public class ResourceObserver;
【推薦】接口類中的方法和屬性不要加任何修飾符号(public 也不要加)，保持代碼的簡潔性，并加上有效的 Javadoc 注釋。盡量不要在接口裡定義變量，如果一定要定義變量，肯定是與接口方法相關，并且是整個應用的基礎常量。
正例:
接口方法簽名 void commit();
接口基礎常量 String COMPANY = "alibaba";
反例:接口方法定義 public abstract void f();
說明:JDK8 中接口允許有預設實作，那麼這個 default 方法，是對所有實作類都有價值的預設實作。
接口和實作類的命名有兩套規則:
【強制】對于 Service 和 DAO 類，基于 SOA 的理念，暴露出來的服務一定是接口，内部的實作類用Impl 的字尾與接口差別。
正例:CacheServiceImpl 實作 CacheService 接口。
【推薦】如果是形容能力的接口名稱，取對應的形容詞為接口名(通常是–able 的形容詞)。
正例:AbstractTranslator 實作 Translatable 接口。
【參考】枚舉類名帶上 Enum 字尾，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。說明:枚舉其實就是特殊的類，域成員均為常量，且構造方法被預設強制是私有。
正例:枚舉名字為 ProcessStatusEnum 的成員名稱:SUCCESS / UNKNOWN_REASON。
【參考】各層命名規約:
Service/DAO 層方法命名規約
擷取單個對象的方法用 get 做字首。
擷取多個對象的方法用 list 做字首，複數形式結尾如:listObjects。
擷取統計值的方法用 count 做字首。
插入的方法用 save/insert 做字首。
删除的方法用 remove/delete 做字首。
修改的方法用 update 做字首。
B) 領域模型命名規約
資料對象:xxxDO，xxx 即為資料表名。
資料傳輸對象:xxxDTO，xxx 為業務領域相關的名稱。
展示對象:xxxVO，xxx 一般為網頁名稱。
POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO。
【強制】不允許任何魔法值(即未經預先定義的常量)直接出現在代碼中。
反例:String key = "Id#taobao_" + tradeId;cache.put(key, value);
// 緩存 get 時，由于在代碼複制時，漏掉下劃線，導緻緩存擊穿而出現問題
【強制】在long或者Long指派時，數值後使用大寫的L，不能是小寫的l，小寫容易跟數字 1 混淆，造成誤解。
說明:Long a = 2l; 寫的是數字的 21，還是 Long 型的 2。
【推薦】不要使用一個常量類維護所有常量，要按常量功能進行歸類，分開維護。說明:大而全的常量類，雜亂無章，使用查找功能才能定位到修改的常量，不利于了解和維護。
正例:緩存相關常量放在類 CacheConsts 下;系統配置相關常量放在類 ConfigConsts 下。
【推薦】常量的複用層次有五層:跨應用共享常量、應用内共享常量、子工程内共享常量、包内共享常量、類内共享常量。
跨應用共享常量:放置在二方庫中，通常是 client.jar 中的 constant 目錄下。
應用内共享常量:放置在一方庫中，通常是子子產品中的 constant 目錄下。
反例:易懂變量也要統一定義成應用内共享常量，兩位工程師在兩個類中分别定義了“YES”的變量:
類 A 中:public static final String YES = "yes";
類 B 中:public static final String YES = "y";
A.YES.equals(B.YES)，預期是 true，但實際傳回為 false，導緻線上問題。
子工程内部共享常量:即在目前子工程的 constant 目錄下。
包内共享常量:即在目前包下單獨的 constant 目錄下。
類内共享常量:直接在類内部 private static final 定義。
【推薦】如果變量值僅在一個固定範圍内變化用enum類型來定義。
說明:如果存在名稱之外的延伸屬性應使用 enum 類型，下面正例中的數字就是延伸資訊，表示一年中的第幾個季節。
代碼塊
【強制】如果是大括号内為空，則簡潔地寫成{}即可，大括号中間無需換行和空格;如果是非
空代碼塊則:
左大括号前不換行。
左大括号後換行。
右大括号前換行。
右大括号後還有 else 等代碼則不換行;表示終止的右大括号後必須換行。
【強制】左小括号和字元之間不出現空格;同樣，右小括号和字元之間也不出現空格;而左大括号前需要空格。詳見第 5 條下方正例提示。
反例:if (空格 a == b 空格)
【強制】if/for/while/switch/do等保留字與括号之間都必須加空格。
【強制】任何二目、三目運算符的左右兩邊都需要加一個空格。
說明:運算符包括指派運算符=、邏輯運算符&&、加減乘除符号等。
【強制】采用4個空格縮進，禁止使用tab字元。
說明:如果使用 tab 縮進，必須設定 1 個 tab 為 4 個空格。IDEA 設定 tab 為 4 個空格時，請勿勾選 Usetab character 。而在 eclipse 中，必須勾選 insert spaces for tabs
正例: (涉及 1-5 點)
【強制】注釋的雙斜線與注釋内容之間有且僅有一個空格。
正例:// 這是示例注釋，請注意在雙斜線之後有一個空格
String param = new String();
【強制】在進行類型強制轉換時，右括号與強制轉換值之間不需要任何空格隔開。
【強制】單行字元數限制不超過120個，超出需要換行，換行時遵循如下原則:
第二行相對第一行縮進 4 個空格，從第三行開始，不再繼續縮進，參考示例。
運算符與下文一起換行。
方法調用的點符号與下文一起換行。
方法調用中的多個參數需要換行時，在逗号後進行。
在括号前不要換行，見反例。
【強制】方法參數在定義和傳入時，多個參數逗号後邊必須加空格。
正例:下例中實參的 args1，後邊必須要有一個空格。method(args1, args2, args3);
【強制】IDE的text file encoding設定為UTF-8; IDE中檔案的換行符使用Unix格式，不 要使用Windows格式。
推薦】單個方法的總行數不超過80行。
說明：除注釋之外的方法簽名、左右大括号、方法内代碼、空行、回車及任何不可見字元的總行數不超過 80行。
正例：代碼邏輯厘清紅花和綠葉，個性和共性，綠葉邏輯單獨出來成為額外方法，使主幹代碼更加清晰； 共性邏輯抽取成為共性方法，便于複用和維護。
【推薦】沒有必要增加若幹空格來使變量的指派等号與上一行對應位置的等号對齊。
Java
說明：增加sb這個變量，如果需要對齊，則給one、two、three都要增加幾個空格，在變量比較多的情 況下，是非常累贅的事情。
【推薦】不同邏輯、不同語義、不同業務的代碼之間插入一個空行分隔開來以提升可讀性。
說明:任何情形，沒有必要插入多個空行進行隔開。
【強制】避免通過一個類的對象引用通路此類的靜态變量或靜态方法，無謂增加編譯器解析成本，直接用類名來通路即可。
【強制】所有的覆寫方法，必須加@Override注解。
說明:getObject()與 get0bject()的問題。一個是字母的 O，一個是數字的 0，加@Override 可以準确判斷是否覆寫成功。另外，如果在抽象類中對方法簽名進行修改，其實作類會馬上編譯報錯。
【強制】相同參數類型，相同業務含義，才可以使用Java的可變參數，避免使用Object。說明:可變參數必須放置在參數清單的最後。(提倡同學們盡量不用可變參數程式設計)
正例:public List<User> listUsers(String type, Long... ids) {...}
【強制】外部正在調用或者二方庫依賴的接口，不允許修改方法簽名，避免對接口調用方産生影響。接口過時必須加@Deprecated 注解，并清晰地說明采用的新接口或者新服務是什
麼。
【強制】不能使用過時的類或方法。
說明:java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已經過時，應該使用雙參數decode(String source, String encode)。接口提供方既然明确是過時接口，那麼有義務同時提供新的接口;作為調用方來說，有義務去考證過時方法的新實作是什麼。
【強制】Object的equals方法容易抛空指針異常，應使用常量或确定有值的對象來調用equals。
正例:"test".equals(object);
反例:object.equals("test");
說明:推薦使用 java.util.Objects#equals(JDK7 引入的工具類)。
【強制】所有整型包裝類對象之間值的比較，全部使用equals方法比較。
說明:對于 Integer var = ? 在-128 至 127 範圍内的指派，Integer 對象是在 IntegerCache.cache 産生，會複用已有對象，這個區間内的 Integer 值可以直接使用==進行判斷，但是這個區間之外的所有資料，都會在堆上産生，并不會複用已有對象，這是一個大坑，推薦使用 equals 方法進行判斷。
【強制】浮點數之間的等值判斷，基本資料類型不能用==來比較，包裝資料類型不能用equals 來判斷。
說明:浮點數采用“尾數+階碼”的編碼方式，類似于科學計數法的“有效數字+指數”的表示方式。二進制無法精确表示大部分的十進制小數，具體原理參考《碼出高效》。
正例：
【強制】定義資料對象DO類時，屬性類型要與資料庫字段類型相比對。
正例:資料庫字段的 bigint 必須與類屬性的 Long 類型相對應。
反例:某個案例的資料庫表 id 字段定義類型 bigint unsigned，實際類對象屬性為 Integer，随着 id 越來越大，超過 Integer 的表示範圍而溢出成為負數。
【強制】為了防止精度損失，禁止使用構造方法 BigDecimal(double)的方式把 double 值轉化為 BigDecimal 對象。
說明:BigDecimal(double)存在精度損失風險，在精确計算或值比較的場景中可能會導緻業務邏輯異常。如:BigDecimal g = new BigDecimal(0.1f); 實際的存儲值為:0.10000000149
正例:優先推薦入參為 String 的構造方法，或使用 BigDecimal 的 valueOf 方法，此方法内部其實執行了Double 的 toString，而 Double 的 toString 按 double 的實際能表達的精度對尾數進行了截斷。
BigDecimal recommend1 = new BigDecimal("0.1");
BigDecimal recommend2 = BigDecimal.valueOf(0.1);
關于基本資料類型與包裝資料類型的使用标準如下:
【強制】所有的 POJO 類屬性必須使用包裝資料類型。
【強制】RPC 方法的傳回值和參數必須使用包裝資料類型。
【推薦】所有的局部變量使用基本資料類型。
說明:POJO 類屬性沒有初值是提醒使用者在需要使用時，必須自己顯式地進行指派，任何 NPE 問題，或者入庫檢查，都由使用者來保證。
正例:資料庫的查詢結果可能是 null，因為自動拆箱，用基本資料類型接收有 NPE 風險。
反例:比如顯示成交總額漲跌情況，即正負 x%，x 為基本資料類型，調用的 RPC 服務，調用不成功時，傳回的是預設值，頁面顯示為 0%，這是不合理的，應該顯示成中劃線。是以包裝資料類的 null 值，能夠表示額外的資訊，如:遠端調用失敗，異常退出。
【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性預設值。
反例:POJO 類的 createTime 預設值為 new Date()，但是這個屬性在資料提取時并沒有置入具體值，在更新其它字段時又附帶更新了此字段，導緻建立時間被修改成目前時間。
【強制】序列化類新增屬性時，請不要修改 serialVersionUID 字段，避免反序列失敗;如果完全不相容更新，避免反序列化混亂，那麼請修改 serialVersionUID 值。
說明:注意 serialVersionUID 不一緻會抛出序列化運作時異常。
【強制】構造方法裡面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
【強制】POJO 類必須寫 toString 方法。使用 IDE 中的工具:source> generate toString時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。說明:在方法執行抛出異常時，可以直接調用 POJO 的 toString()方法列印其屬性值，便于排查問題。
【強制】禁止在POJO類中，同時存在對應屬性xxx的isXxx()和getXxx()方法。
說明：架構在調用屬性xxx的提取方法時，并不能确定哪個方法一定是被優先調用到。
【推薦】使用索引通路用 String 的 split 方法得到的數組時，需做最後一個分隔符後有無内容的檢查，否則會有抛 IndexOutOfBoundsException 的風險。
說明:
【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一起，便于閱讀，此條規則優先于下一條。
【推薦】 類内方法定義的順序依次是:公有方法或保護方法 > 私有方法 > getter / setter方法。
說明:公有方法是類的調用者和維護者最關心的方法，首屏展示最好;保護方法雖然隻是子類關心，也可能是“模闆設計模式”下的核心方法；而私有方法外部一般不需要特别關心，是一個黑盒實作；因為承載 的資訊價值較低，所有 Service 和 DAO 的 getter/setter 方法放在類體最後。
【推薦】setter 方法中，參數名稱與類成員變量名稱一緻，this.成員名 = 參數名。在getter/setter 方法中，不要增加業務邏輯，增加排查問題的難度。
【推薦】循環體内，字元串的連接配接方式，使用 StringBuilder 的 append 方法進行擴充。說明:下例中，反編譯出的位元組碼檔案顯示每次循環都會 new 出一個 StringBuilder 對象，然後進行append 操作，最後通過 toString 方法傳回 String 對象，造成記憶體資源浪費。
【推薦】final 可以聲明類、成員變量、方法、以及本地變量，下列情況使用 final 關鍵字:
不允許被繼承的類，如:String 類。
不允許修改引用的域對象。
不允許被覆寫的方法，如:POJO 類的 setter 方法。
不允許運作過程中重新指派的局部變量。
避免上下文重複使用一個變量，使用 final 可以強制重新定義一個變量，友善更好地進行重構。
【推薦】慎用 Object 的 clone 方法來拷貝對象。
說明:對象 clone 方法預設是淺拷貝，若想實作深拷貝需覆寫 clone 方法實作域對象的深度周遊式拷貝。
【推薦】類成員與方法通路控制從嚴:
如果不允許外部直接通過 new 來建立對象，那麼構造方法必須是 private。
工具類不允許有 public 或 default 構造方法。
類非 static 成員變量并且與子類共享，必須是 protected。
類非 static 成員變量并且僅在本類使用，必須是 private。
類 static 成員變量如果僅在本類使用，必須是 private。
若是 static 成員變量，考慮是否為 final。
類成員方法隻供類内部調用，必須是 private。
類成員方法隻對繼承類公開，那麼限制為 protected。
說明:任何類、方法、參數、變量，嚴控通路範圍。過于寬泛的通路範圍，不利于子產品解耦。思考:如果是一個 private 的方法，想删除就删除，可是一個 public 的 service 成員方法或成員變量，删除一下，不得手心冒點汗嗎?變量像自己的小孩，盡量在自己的視線内，變量作用域太大，無限制的到處跑，那麼你會擔心的。
【強制】關于hashCode和equals的處理，遵循如下規則:
隻要覆寫 equals，就必須覆寫 hashCode。
因為 Set 存儲的是不重複的對象，依據 hashCode 和 equals 進行判斷，是以 Set 存儲的對象必須覆寫這兩個方法。
如果自定義對象作為 Map 的鍵，那麼必須覆寫 hashCode 和 equals。
說明:String 已覆寫 hashCode 和 equals 方法，是以我們可以愉快地使用 String 對象作為 key 來使用。
【強制】ArrayList 的 subList 結果不可強轉成 ArrayList，否則會抛出 ClassCastException 異常，即 java.util.RandomAccessSubList cannot be cast to java.util.ArrayList。
說明:subList 傳回的是 ArrayList 的内部類 SubList，并不是 ArrayList 而是 ArrayList 的一個視圖，對于 SubList 子清單的所有操作最終會反映到原清單上。
【強制】使用Map的方法keySet()/values()/entrySet()傳回集合對象時，不可以對其進行添加元素操作，否則會抛出 UnsupportedOperationException 異常。
【強制】Collections 類傳回的對象，如：emptyList()/singietonList()等都是 immutable list，不可對其進行添加或者删除元素的操作。
反例：如果查詢無結果，傳回Collections.emptyList()空集合對象，調用方一旦進行了添加元素的操作，就會觸發 UnsupportedOperationException 異常。
【強制】在subList場景中，高度注意對原集合元素的增加或删除，均會導緻子清單的周遊、增加、删除産生 ConcurrentModificationException 異常。
【強制】使用集合轉數組的方法，必須使用集合的toArray(T[] array)，傳入的是類型完全一緻、長度為0的空數組。
反例：直接使用toArray無參方法存在問題，此方法傳回值隻能是Object[]類，若強轉其它類型數組将出 現 ClassCastException錯誤。
說明：使用toArray帶參方法，數組空間大小的length :
等于0，動态建立與size相同的數組，性能最好。
大于0但小于size，重新建立大小等于size的數組，增加GC負擔。
等于size，在高并發情況下，數組建立完成之後，size正在變大的情況下，負面影響與上相同。
4)大于size，空間浪費，且在size處插入null值，存在NPE隐患。
【強制】在使用Collection接口任何實作類的addAII()方法時，都要對輸入的集合參數進行 NPE判斷。
說明：在ArrayList#addAII方法的第一行代碼即Object]] a = c.toArrayO;其中c為輸入集合參數，如果 為null，則直接抛出異常。
【強制】使用工具類Arrays.asList()把數組轉換成集合時，不能使用其修改集合相關的方法，它的 add/remove/clear 方法會抛出 UnsupportedOperationException 異常。
說明:asList 的傳回對象是一個 Arrays 内部類，并沒有實作集合的修改方法。Arrays.asList 展現的是擴充卡模式，隻是轉換接口，背景的資料仍是數組。
第一種情況:list.add("yangguanbao"); 運作時異常。
第二種情況:str[0] = "changed"; 也會随之修改，反之亦然。
【強制】泛型通配符<?extendsT>來接收傳回的資料，此寫法的泛型集合不能使用add方法，而<? super T>不能使用 get 方法，作為接口調用指派時易出錯。
說明:擴充說一下 PECS(Producer Extends Consumer Super)原則:第一、頻繁往外讀取内容的，适合用<? extends T>。第二、經常往裡插入的，适合用<? super T>
【強制】在無泛型限制定義的集合指派給泛型限制的集合時，在使用集合元素時，需要進行instanceof 判斷，避免抛出 ClassCastException 異常。
說明:畢竟泛型是在 JDK5 後才出現，考慮到向前相容，編譯器是允許非泛型集合與泛型集合互相指派。
【強制】不要在 foreach 循環裡進行元素的 remove/add 操作。remove 元素請使用Iterator 方式，如果并發操作，需要對 Iterator 對象加鎖。
說明:以上代碼的執行結果肯定會出乎大家的意料，那麼試一下把“1”換成“2”，會是同樣的結果嗎?
【強制】在 JDK7 版本及以上，Comparator 實作類要滿足如下三個條件，不然 Arrays.sort，Collections.sort 會抛 IllegalArgumentException 異常。
說明:三個條件如下
x，y 的比較結果和 y，x 的比較結果相反。
x>y，y>z，則 x>z。
x=y，則 x，z 比較結果和 y，z 比較結果相同。
反例:下例中沒有處理相等的情況，交換兩個對象判斷結果并不互反，不符合第一個條件，在實際使用中可能會出現異常。
【推薦】集合泛型定義時，在 JDK7 及以上，使用 diamond 文法或全省略。
說明:菱形泛型，即 diamond，直接使用<>來指代前邊已經指定的類型。
【推薦】集合初始化時，指定集合初始值大小。
說明:HashMap 使用 HashMap(int initialCapacity) 初始化。
正例:initialCapacity = (需要存儲的元素個數 / 負載因子) + 1。注意負載因子(即 loader factor)預設為 0.75，如果暫時無法确定初始值大小，請設定為 16(即預設值)。
反例:HashMap 需要放置 1024 個元素，由于沒有設定容量初始大小，随着元素不斷增加，容量 7 次被迫擴大，resize 需要重建 hash 表，嚴重影響性能。
【推薦】使用 entrySet 周遊 Map 類集合 KV，而不是 keySet 方式進行周遊。
說明:keySet 其實是周遊了 2 次，一次是轉為 Iterator 對象，另一次是從 hashMap 中取出 key 所對應的 value。而 entrySet 隻是周遊了一次就把 key 和 value 都放到了 entry 中，效率更高。如果是 JDK8，使用 Map.forEach 方法。
正例:values()傳回的是 V 值集合，是一個 list 集合對象;keySet()傳回的是 K 值集合，是一個 Set 集合對象;entrySet()傳回的是 K-V 值組合集合。
【推薦】高度注意 Map 類集合 K/V 能不能存儲 null 值的情況，如下表格:
反例:由于 HashMap 的幹擾，很多人認為 ConcurrentHashMap 是可以置入 null 值，而事實上，存儲null 值時會抛出 NPE 異常。
【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和不穩定性(unorder)帶來的負面影響。說明:有序性是指周遊的結果是按某種比較規則依次排列的。穩定性指集合每次周遊的元素次序是一定的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort。
【參考】利用 Set 元素唯一的特性，可以快速對一個集合進行去重操作，避免使用 List 的contains 方法進行周遊、對比、去重操作。
【強制】擷取單例對象需要保證線程安全，其中的方法也要保證線程安全。
說明:資源驅動類、工具類、單例工廠類都需要注意。
【強制】建立線程或線程池時請指定有意義的線程名稱，友善出錯時回溯。
正例:自定義線程工廠，并且根據外部特征進行分組，比如機房資訊。
【強制】線程資源必須通過線程池提供，不允許在應用中自行顯式建立線程。說明:線程池的好處是減少在建立和銷毀線程上所消耗的時間以及系統資源的開銷，解決資源不足的問
題。如果不使用線程池，有可能造成系統建立大量同類線程而導緻消耗完記憶體或者“過度切換”的問題。
【強制】線程池不允許使用Executors去建立，而是通過ThreadPoolExecutor的方式，這樣的處理方式讓寫的同學更加明确線程池的運作規則，規避資源耗盡的風險。
說明:Executors 傳回的線程池對象的弊端如下:
FixedThreadPool 和 SingleThreadPool:允許的請求隊列長度為 Integer.MAX_VALUE，可能會堆積大量的請求，進而導緻 OOM。
CachedThreadPool:允許的建立線程數量為 Integer.MAX_VALUE，可能會建立大量的線程，進而導緻 OOM。
【強制】SimpleDateFormat 是線程不安全的類，一般不要定義為static變量，如果定義為static，必須加鎖，或者使用 DateUtils 工具類。
正例:注意線程安全，使用 DateUtils。亦推薦如下處理:
說明:如果是 JDK8 的應用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方給出的解釋:simple beautiful strong immutable
thread-safe。
【強制】必須回收自定義的ThreadLocal變量，尤其線上程池場景下，線程經常會被複用，如果不清理自定義的 ThreadLocal 變量，可能會影響後續業務邏輯和造成記憶體洩露等問題。
盡量在代理中使用 try-finally 塊進行回收。
【強制】高并發時，同步調用應該去考量鎖的性能損耗。能用無鎖資料結構，就不要用鎖;能鎖區塊，就不要鎖整個方法體;能用對象鎖，就不要用類鎖。
說明:盡可能使加鎖的代碼塊工作量盡可能的小，避免在鎖代碼塊中調用 RPC 方法。
【強制】對多個資源、資料庫表、對象同時加鎖時，需要保持一緻的加鎖順序，否則可能會造成死鎖。
說明:線程一需要對表 A、B、C 依次全部加鎖後才可以進行更新操作，那麼線程二的加鎖順序也必須是A、B、C，否則可能出現死鎖。
【強制】在使用阻塞等待擷取鎖的方式中，必須在try代碼塊之外，并且在加鎖方法與try代碼塊之間沒有任何可能抛出異常的方法調用，避免加鎖成功後，在 finally 中無法解鎖。
說明一:如果在 lock 方法與 try 代碼塊之間的方法調用抛出異常，那麼無法解鎖，造成其它線程無法成功擷取鎖。
說明二:如果 lock 方法在 try 代碼塊之内，可能由于其它方法抛出異常，導緻在 finally 代碼塊中，unlock 對未加鎖的對象解鎖，它會調用 AQS 的 tryRelease 方法(取決于具體實作類)，抛出IllegalMonitorStateException 異常。
說明三:在 Lock 對象的 lock 方法實作中可能抛出 unchecked 異常，産生的後果與說明二相同。
【強制】在使用嘗試機制來擷取鎖的方式中，進入業務代碼塊之前，必須先判斷目前線程是 否持有鎖。鎖的釋放規則與鎖的阻塞等待方式相同。
說明：Lock對象的unlock方法在執行時，它會調用AQS的tryRelease方法（取決于具體實作類），如果 目前線程不持有鎖，則抛出IllegalMonitorStateException異常。
【強制】并發修改同一記錄時，避免更新丢失，需要加鎖。要麼在應用層加鎖，要麼在緩存加鎖，要麼在資料庫層使用樂觀鎖，使用 version 作為更新依據。說明:如果每次通路沖突機率小于 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數不得小于3 次。
【強制】多線程并行處理定時任務時，Timer 運作多個 TimeTask 時，隻要其中之一沒有捕獲抛出的異常，其它任務便會自動終止運作，如果在處理定時任務時使用ScheduledExecutorService 則沒有這個問題。
【推薦】資金相關的金融敏感資訊，使用悲觀鎖政策。
說明：樂觀鎖在獲得鎖的同時已經完成了更新操作，校驗邏輯容易出現漏洞，另外，樂觀鎖對沖突的解決政策有較複雜的要求，處理不當容易造成系統壓力或資料異常，是以資金相關的金融敏感資訊不建議使用 樂觀鎖更新。
【推薦】使用 CountDownLatch 進行異步轉同步操作，每個線程退出前必須調用 countDown方法，線程執行代碼注意 catch 異常，確定 countDown 方法被執行到，避免主線程無法執行至 await 方法，直到逾時才傳回結果。
說明:注意，子線程抛出異常堆棧，不能在主線程 try-catch 到。
【推薦】避免 Random 執行個體被多線程使用，雖然共享該執行個體是線程安全的，但會因競争同一seed 導緻的性能下降。
說明:Random 執行個體包括 java.util.Random 的執行個體或者 Math.random()的方式。
正例:在 JDK7 之後，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要編碼保證每個線程持有一個執行個體。
【推薦】在并發場景下，通過雙重檢查鎖(double-checked locking)實作延遲初始化的優化問題隐患(可參考 The "Double-Checked Locking is Broken" Declaration)，推薦解決方案中較為簡單一種(适用于 JDK5 及以上版本)，将目标屬性聲明為 volatile 型。
【參考】volatile 解決多線程記憶體不可見問題。對于一寫多讀，是可以解決變量同步問題，但是如果多寫，同樣無法解決線程安全問題。
說明:如果是 count++操作，使用如下類實作:AtomicInteger count = new AtomicInteger();count.addAndGet(1); 如果是 JDK8，推薦使用 LongAdder 對象，比 AtomicLong 性能更好(減少樂觀
鎖的重試次數)。
【參考】HashMap 在容量不夠進行 resize 時由于高并發可能出現死鍊，導緻 CPU 飙升，在開發過程中可以使用其它資料結構或加鎖來規避此風險。
【參考】ThreadLocal 對象使用 static 修飾，ThreadLocal 無法解決共享對象的更新問題。
說明:這個變量是針對一個線程内所有操作共享的，是以設定為靜态變量，所有此類執行個體共享此靜态變量，也就是說在類第一次被使用時裝載，隻配置設定一塊存儲空間，所有此類的對象(隻要是這個線程内定義的)都可以操控這個變量。
【強制】在一個switch塊内，每個case要麼通過continue/break/return等來終止，要麼注釋說明程式将繼續執行到哪一個 case 為止;在一個 switch 塊内，都必須包含一個default 語句并且放在最後，即使它什麼代碼也沒有。
說明:注意 break 是退出 switch 語句塊，而 return 是退出方法體。
【強制】當switch括号内的變量類型為String并且此變量為外部參數時，必須先進行null判斷。
反例:猜猜下面的代碼輸出是什麼?
【強制】在if/else/for/while/do語句中必須使用大括号。
說明:即使隻有一行代碼，避免采用單行的編碼方式:if (condition) statements;
【強制】在高并發場景中，避免使用"等于"判斷作為中斷或退出的條件。
說明：如果并發控制沒有處理好，容易産生等值判斷被"擊穿"的情況，使用大于或小于的區間判斷條件來代替。
反例：判斷剩餘獎品數量等于0時，終止發放獎品，但因為并發處理錯誤導緻獎品數量瞬間變成了負數， 這樣的話，活動無法終止。
【推薦】表達異常的分支時，少用if-else方式，這種方式可以改寫成:
說明：如果非使用if()...else if()...else...方式表達邏輯，避免後續代碼維護困難，【強制】請勿超過3層。
正例：超過 3 層的 if-else 的邏輯判斷代碼可以使用衛語句、政策模式、狀态模式等來實作，其中衛語句即代碼邏輯先考慮失敗、異常、中斷、退出等直接傳回的情況，以方法多個出口的方式，解決代碼中判斷 分支嵌套的問題，這是逆向思維的展現。示例如下：
【推薦】除常用方法(如getXxx/isXxx)等外，不要在條件判斷中執行其它複雜的語句，将複雜邏輯判斷的結果指派給一個有意義的布爾變量名，以提高可讀性。
說明:很多 if 語句内的邏輯表達式相當複雜，與、或、取反混合運算，甚至各種方法縱深調用，了解成本非常高。如果指派一個非常好了解的布爾變量名字，則是件令人爽心悅目的事情。
【推薦】不要在其它表達式(尤其是條件表達式)中，插入指派語句。
說明:指派點類似于人體的穴位，對于代碼的了解至關重要，是以指派語句需要清晰地單獨成為一行。
【推薦】循環體中的語句要考量性能，以下操作盡量移至循環體外處理，如定義對象、變量、擷取資料庫連接配接，進行不必要的 try-catch 操作(這個 try-catch 是否可以移至循環體外)。
【推薦】避免采用取反邏輯運算符。
說明：取反邏輯不利于快速了解，并且取反邏輯寫法必然存在對應的正向邏輯寫法。
正例：使用if (x < 628)來表達x小于628。
反例：使用if (!(x >=628))來表達x小于628。
【推薦】接口入參保護，這種場景常見的是用作批量操作的接口。
【參考】下列情形，需要進行參數校驗:
調用頻次低的方法。
執行時間開銷很大的方法。此情形中，參數校驗時間幾乎可以忽略不計，但如果因為參數錯誤導緻中間執行回退，或者錯誤，那得不償失。
需要極高穩定性和可用性的方法。
對外提供的開放接口，不管是 RPC/API/HTTP 接口。
敏感權限入口。
【參考】下列情形，不需要進行參數校驗:
極有可能被循環調用的方法。但在方法說明裡必須注明外部參數檢查要求。
底層調用頻度比較高的方法。畢竟是像純淨水過濾的最後一道，參數錯誤不太可能到底層才會暴露問題。一般 DAO 層與 Service 層都在同一個應用中，部署在同一台伺服器中，是以 DAO 的參數校驗，可以省略。
【強制】類、類屬性、類方法的注釋必須使用Javadoc規範，使用/**内容*/格式，不得使用// xxx 方式。
說明:在 IDE 編輯視窗中，Javadoc 方式會提示相關注釋，生成 Javadoc 可以正确輸出相應注釋;在 IDE中，工程調用方法時，不進入方法即可懸浮提示方法、參數、傳回值的意義，提高閱讀效率。
【強制】所有的抽象方法(包括接口中的方法)必須要用Javadoc注釋、除了傳回值、參數、異常說明外，還必須指出該方法做什麼事情，實作什麼功能。說明:對子類的實作要求，或者調用注意事項，請一并說明。
【強制】所有的類都必須添加建立者和建立日期。
【強制】方法内部單行注釋，在被注釋語句上方另起一行，使用//注釋。方法内部多行注釋使用/* */注釋，注意與代碼對齊。
【強制】所有的枚舉類型字段必須要有注釋，說明每個資料項的用途。
【推薦】與其“半吊子”英文來注釋，不如用中文注釋把問題說清楚。專有名詞與關鍵字保持英文原文即可。
反例:“TCP 連接配接逾時”解釋成“傳輸控制協定連接配接逾時”，了解反而費腦筋。
【推薦】代碼修改的同時，注釋也要進行相應的修改，尤其是參數、傳回值、異常、核心邏輯等的修改。
說明:代碼與注釋更新不同步，就像路網與導航軟體更新不同步一樣，如果導航軟體嚴重滞後，就失去了導航的意義。
【參考】謹慎注釋掉代碼。在上方詳細說明，而不是簡單地注釋掉。如果無用，則删除。
說明:代碼被注釋掉有兩種可能性:1)後續會恢複此段代碼邏輯。2)永久不用。前者如果沒有備注資訊，難以知曉注釋動機。後者建議直接删掉(代碼倉庫已然儲存了曆史代碼)。
【參考】對于注釋的要求:第一、能夠準确反映設計思想和代碼邏輯;第二、能夠描述業務含義，使别的程式員能夠迅速了解到代碼背後的資訊。完全沒有注釋的大段代碼對于閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能清晰了解當時的思路;注釋也是給繼任者看的，使其能夠快速接替自己的工作。
【參考】好的命名、代碼結構是自解釋的，注釋力求精簡準确、表達到位。避免出現注釋的一個極端:過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔。
【參考】特殊注釋标記，請注明标記人與标記時間。注意及時處理這些标記，通過标記掃描，經常清理此類标記。線上故障有時候就是來源于這些标記處的代碼。
待辦事宜(TODO):(标記人，标記時間，[預計處理時間])表示需要實作，但目前還未實作的功能。這實際上是一個 Javadoc 的标簽，目前的 Javadoc 還沒有實作，但已經被廣泛使用。隻能應用于類，接口和方法(因為它是一個 Javadoc 标簽)。
錯誤，不能工作(FIXME):(标記人，标記時間，[預計處理時間])在注釋中用 FIXME 标記某代碼是錯誤的，而且不能工作，需要及時糾正的情況。
【強制】在使用正規表達式時，利用好其預編譯功能，可以有效加快正則比對速度。
說明:不要在方法體内定義:Pattern pattern = Pattern.compile(“規則”);
【強制】velocity調用POJO類的屬性時，直接使用屬性名取值即可，模闆引擎會自動按規範調用 POJO 的 getXxx()，如果是 boolean 基本資料類型變量(boolean 命名不需要加 is 字首)，會自動調用 isXxx()方法。
說明:注意如果是 Boolean 包裝類對象，優先調用 getXxx()的方法。
【強制】背景輸送給頁面的變量必須加$!{var}——中間的感歎号。
說明:如果 var 等于 null 或者不存在，那麼${var}會直接顯示在頁面上。
【強制】注意 Math.random() 這個方法傳回是 double 類型，注意取值的範圍 0≤x<1(能夠取到零值，注意除零異常)，如果想擷取整數類型的随機數，不要将 x 放大 10 的若幹倍然後取整，直接使用 Random 對象的 nextInt 或者 nextLong 方法。
【強制】擷取目前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime();
說明:如果想擷取更加精确的納秒級時間值，使用 System.nanoTime()的方式。在 JDK8 中，針對統計時間等場景，推薦使用 Instant 類。
【強制】日期格式化時，傳入pattern中表示年份統一使用小寫的y。
說明:日期格式化時，yyyy 表示當天所在的年，而大寫的 YYYY 代表是 week in which year(JDK7 之後引入的概念)，意思是當天所在的周屬于的年份，一周從周日開始，周六結束，
隻要本周跨年，傳回的 YYYY 就是下一年。另外需要注意:
表示月份是大寫的M
表示分鐘則是小寫的m
24小時制的是大寫的H
12小時制的則是小寫的h
正例：表示日期和時間的格式如下所示：new SimpleDateFormat(”yyyy_MM_dd HH:mm:ss");
【推薦】不要在視圖模闆中加入任何複雜的邏輯。
說明:根據 MVC 理論，視圖的職責是展示，不要搶模型和控制器的活。
【推薦】任何資料結構的構造或初始化，都應指定大小，避免資料結構無限增長吃光記憶體。
【推薦】及時清理不再使用的代碼段或配置資訊。
說明:對于垃圾代碼或過時配置，堅決清理幹淨，避免程式過度臃腫，代碼備援。
正例:對于暫時被注釋掉，後續可能恢複使用的代碼片斷，在注釋代碼上方，統一規定使用三個斜杠(///)來說明注釋掉代碼的理由。
【強制】Java類庫中定義的可以通過預檢查方式規避的RuntimeException異常不應該通過 catch 的方式來處理，比如：NullPointerException，IndexOutOfBoundsException 等 等。
說明：無法通過預檢查的異常除外，比如，在解析字元串形式的數字時，可育猖在數字格式錯誤，不得不通過 catchNumberFormatException 來實作。
正例：if (obj != null) {...}
反例:try {obj.methodO; } catch (NullPointerException e) {...}
【強制】異常不要用來做流程控制，條件控制。
說明：異常設計的初衷是解決程式運作中的各種意外情況，且異常的處理效率比條件判斷方式要低很多。
【強制】catch時請厘清穩定代碼和非穩定代碼，穩定代碼指的是無論如何不會出錯的代碼。對于非穩定代碼的catch盡可能進行區分異常類型，再做對應的異常處理。
說明：對大段代碼進行try-catch，使程式無法根據不同的異常做出正确的應激反應，也不利于定位問 題，這是一種不負責任的表現。
正例：使用者注冊的場景中，如果使用者輸入非法字元，或使用者名稱已存在，或使用者輸入密碼過于簡單，在程式上作出分門别類的判斷，并提示給使用者。
【強制】捕獲異常是為了處理它，不要捕獲了卻什麼都不處理而抛棄之，如果不想處理它，請将該異常抛給它的調用者。最外層的業務使用者，必須處理異常，将其轉化為使用者可以理
解的内容。
【強制】有try塊放到了事務代碼中，catch異常後，如果需要復原事務，一定要注意手動復原事務。
【強制】finally塊必須對資源對象、流對象進行關閉，有異常也要做try-catch。
說明:如果 JDK7 及以上，可以使用 try-with-resources 方式。
【強制】不要在finally塊中使用return。
說明:try 塊中的 return 語句執行成功後，并不馬上傳回，而是繼續執行 finally 塊中的語句，如果此處存在 return 語句，則在此直接傳回，無情丢棄掉 try 塊中的傳回點。
【強制】捕獲異常與抛異常，必須是完全比對，或者捕獲異常是抛異常的父類。
說明:如果預期對方抛的是繡球，實際接到的是鉛球，就會産生意外情況。
【強制】在調用RPC、二方包、或動态生成類的相關方法時，捕捉異常必須使用Throwable 類來進行攔截。
說明：通過反射機制來調用方法，如果找不到方法，抛出NoSuchMethodException。什麼情況會抛出 NoSuchMethodError呢？二方包在類沖突時，仲裁機制可能導緻引入非預期的版本使類的方法簽名不匹 配，或者在位元組碼修改架構(比如：ASM)動态建立或修改類時，修改了相應的方法簽名。這些情況，即 使代碼編譯期是正确的，但在代碼運作期時，會抛出NoSuchMethodError。
【推薦】方法的傳回值可以為 null，不強制傳回空集合，或者空對象等，必須添加注釋充分說明什麼情況下會傳回 null 值。
說明:本手冊明确防止 NPE 是調用者的責任。即使被調用方法傳回空集合或者空對象，對調用者來說，也并非高枕無憂，必須考慮到遠端調用失敗、序列化失敗、運作時異常等場景傳回 null 的情況。
【推薦】防止 NPE，是程式員的基本修養，注意 NPE 産生的場景:
傳回類型為基本資料類型，return 包裝資料類型的對象時，自動拆箱有可能産生 NPE。
反例:public int f() { return Integer 對象}， 如果為 null，自動解箱抛 NPE。
資料庫的查詢結果可能為 null。
集合裡的元素即使 isNotEmpty，取出的資料元素也可能為 null。
遠端調用傳回對象時，一律要求進行空指針判斷，防止 NPE。
對于 Session 中擷取的資料，建議進行 NPE 檢查，避免空指針。6) 級聯調用 obj.getA().getB().getC();一連串調用，易産生 NPE。
正例:使用 JDK8 的 Optional 類來防止 NPE 問題。
【推薦】定義時區分 unchecked / checked 異常，避免直接抛出 new RuntimeException()，更不允許抛出 Exception 或者 Throwable，應使用有業務含義的自定義異常。推薦業界已定義過的自定義異常，如:DAOException / ServiceException 等。
【參考】對于公司外的 http/api 開放接口必須使用“錯誤碼”;而應用内部推薦異常抛出;跨應用間 RPC 調用優先考慮使用 Result 方式，封裝 isSuccess()方法、“錯誤碼”、“錯誤
簡短資訊”。
說明:關于 RPC 方法傳回方式使用 Result 方式的理由:
使用抛異常傳回方式，調用方如果沒有捕獲到就會産生運作時錯誤。
如果不加棧資訊，隻是 new 自定義異常，加入自己的了解的 error message，對于調用端解決問題的幫助不會太多。如果加了棧資訊，在頻繁調用出錯的情況下，資料序列化和傳輸的性能損耗也是問題。
【參考】避免出現重複的代碼(Don't Repeat Yourself)，即 DRY 原則。說明:随意複制和粘貼代碼，必然會導緻代碼的重複，在以後需要修改時，需要修改所有的副本，容易遺
漏。必要時抽取共性方法，或者抽象公共類，甚至是元件化。
正例:一個類中有多個 public 方法，都需要進行數行相同的參數校驗操作，這個時候請抽取:private boolean checkParam(DTO dto) {...}
【強制】應用中不可直接使用日志系統(Log4j、Logback)中的API，而應依賴使用日志架構SLF4J 中的 API，使用門面模式的日志架構，有利于維護和各個類的日志處理方式統一。
【強制】所有日志檔案至少儲存15天，因為有些異常具備以“周”為頻次發生的特點。網絡運作狀态、安全相關資訊、系統監測、管理背景操作、使用者敏感操作需要留存相關的網絡日
志不少于 6 個月。
【強制】應用中的擴充日志(如打點、臨時監控、通路日志等)命名方式:appName_logType_logName.log。logType:日志類型，如 stats/monitor/access 等;logName:日志描述。這種命名的好處:通過檔案名就可知道日志檔案屬于什麼應用，什麼類型，什麼目的，也有利于歸類查找。說明:推薦對日志進行分類，如将錯誤日志和業務日志分開存放，便于開發人員檢視，也便于通過日志對系統進行及時監控。
正例:force-web 應用中單獨監控時區轉換異常，如:force_web_timeZoneConvert.log
【強制】在日志輸出時，字元串變量之間的拼接使用占位符的方式。
說明:因為 String 字元串的拼接會使用 StringBuilder 的 append()方式，有一定的性能損耗。使用占位符僅是替換動作，可以有效提升性能。
正例:logger.debug("Processing trade with id: {} and symbol: {}", id, symbol);
【強制】對于trace/debug/info級别的日志輸出，必須進行日志級别的開關判斷。說明:雖然在 debug(參數)的方法體内第一行代碼 isDisabled(Level.DEBUG_INT)為真時(Slf4j 的常見實作 Log4j 和 Logback)，就直接 return，但是參數可能會進行字元串拼接運算。此外，如果debug(getName())這種參數内有 getName()方法調用，無謂浪費方法調用的開銷。
【強制】避免重複列印日志，浪費磁盤空間，務必在log4j.xml中設定additivity=false。
正例:<logger name="com.taobao.dubbo.config" additivity="false">
【強制】異常資訊應該包括兩類資訊:案發現場資訊和異常堆棧資訊。如果不處理，那麼通過關鍵字 throws 往上抛出。
正例:logger.error(各類參數或者對象 toString() + "_" + e.getMessage(), e);
【推薦】謹慎地記錄日志。生産環境禁止輸出debug日志;有選擇地輸出info日志;如果使用 warn 來記錄剛上線時的業務行為資訊，一定要注意日志輸出量的問題，避免把伺服器磁盤撐爆，并記得及時删除這些觀察日志。
說明:大量地輸出無效日志，不利于系統性能提升，也不利于快速定位錯誤點。記錄日志時請思考:這些日志真的有人看嗎?看到這條日志你能做什麼?能不能給問題排查帶來好處?
【推薦】可以使用warn日志級别來記錄使用者輸入參數錯誤的情況，避免使用者投訴時，無所 适從。如非必要，請不要在此場景打出error級别，避免頻繁報警。
說明：注意日志輸出的級别，error級别隻記錄系統邏輯出錯、異常或者重要的錯誤資訊。
【推薦】盡量用英文來描述日志錯誤資訊，如果日志中的錯誤資訊用英文描述不清楚的話使 用中文描述即可，否則容易産生歧義。【強制】國際化團隊或海外部署的伺服器由于字元集 問題，使用全英文來注釋和描述日志錯誤資訊
【強制】好的單元測試必須遵守AIR原則。
說明：單元測試線上上運作時，感覺像空氣（AIR ）—樣并不存在，但在測試品質的保障上，卻是非常關 鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。
A : Automatic（自動化）
I : Independent（獨立性）
R : Repeatable（可重複）
【強制】單元測試應該是全自動執行的，并且非互動式的。測試用例通常是被定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。 單元測試中不準使用System.out來進行人肉驗證，必須使用assert來驗證。
【強制】保持單元測試的獨立性。為了保證單元測試穩定可靠且便于維護，單元測試用例之間決不能互相調用，也不能依賴執行的先後次序。
反例：method2需要依賴method1的執行，将執行結果作為method2的輸入。
【強制】單元測試是可以重複執行的，不能受到外界環境的影響。
說明：單元測試通常會被放到持續內建中，每次有代碼check in時單元測試都會被執行。如果單測對外部 環境（網絡、月服務、中間件等）有依賴，容易導緻持續內建機制的不可用。
正例：為了不受外界環境影響，要求設計代碼時就把SUT的依賴改成注入，在測試時用spring這樣的DI 架構注入一個本地（記憶體）實作或者Mock實作。
【強制】對于單元測試，要保證測試粒度足夠小，有助于精确定位問題。單測粒度至多是類級别，一般是方法級别。
說明：隻有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負責檢查跨類或者跨系統的互動邏輯，那是內建測試的領域。
【強制】核心業務、核心應用、核心子產品的增量代碼確定單元測試通過。
說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。
【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。
說明：源碼編譯時會跳過此目錄，而單元測試架構預設是掃描此目錄。
【推薦】單元測試的基本目标：語句覆寫率達到70% ；核心子產品的語句覆寫率和分支覆寫率 都要達到100%
說明：在工程規約的應用分層中提到的DAO層，Manager層，可重用度高的Service，都應該進行單元 測試。
【推薦】編寫單元測試代碼遵守BCDE原則，以保證被測試子產品的傳遞品質。
B : Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、資料順序等。
C :Correct，正确的輸入，并得到預期的結果。
D : Design，與設計文檔相結合，來編寫單元測試。
E : Error，強制錯誤資訊輸入（如：非法資料、異常流程、業務允許外等），并得到預期的結果。
推薦】對于資料庫相關的查詢，更新，删除等操作，不能假設資料庫裡的資料是存在的，或者直接操作資料庫把資料插入進去，請使用程式插入或者導入資料的方式來準備資料。 反例：删除某一行資料的單元測試，在資料庫中，先直接手動增加一行作為删除目标，但是這一行新增資料并不符合業務插入規則，導緻測試結果異常。
【推薦】和資料庫相關的單元測試，可以設定自動復原機制，不給資料庫造成髒資料。或者對單元測試産生的資料有明确的前字尾辨別。
正例：在企業智能事業部的内部單元測試中，使用ENTERPRISE_INTELLIGENCE _UNIT_TEST_的字首來 辨別單元測試相關代碼。
【推薦】對于不可測的代碼在适當的時機做必要的重構，使代碼變得可測，避免為了達到測試要求而書寫不規範測試代碼。
【推薦】在設計評審階段，開發人員需要和測試人員一起确定單元測試範圍，單元測試最好 覆寫所有測試用例。
【推薦】單元測試作為一種品質保障手段，在項目提測前完成單元測試，不建議項目釋出後 補充單元測試用例。
【參考】為了更友善地進行單元測試，業務代碼應避免以下情況：
構造方法中做的事情過多。
存在過多的全局變量和靜态方法
存在過多的外部依賴。
存在過多的條件語句。
說明：多層條件語句建議使用衛語句、政策模式、狀态模式等方式重構。
【參考】不要對單元測試存在如下誤解：
那是測試同學幹的事情。本文是開發手冊，凡是本文内容都是與開發同學強相關的。
單元測試代碼是多餘的。系統的整體功能與各單元部件的測試正常與否是強相關的。
單元測試代碼不需要維護。一年半載後，那麼單元測試幾乎處于廢棄狀态。
單元測試與線上故障沒有辯證關系。好的單元測試能夠最大限度地規避線上故障。
【強制】隸屬于使用者個人的頁面或者功能必須進行權限控制校驗。說明:防止沒有做水準權限校驗就可随意通路、修改、删除别人的資料，比如檢視他人的私信内容、修改他人的訂單。
【強制】使用者敏感資料禁止直接展示，必須對展示資料進行脫敏。說明:中國大陸個人手機号碼顯示為:137****0969，隐藏中間 4 位，防止隐私洩露。
【強制】使用者輸入的SQL參數嚴格使用參數綁定或者METADATA字段值限定，防止SQL注入，禁止字元串拼接 SQL 通路資料庫。
【強制】使用者請求傳入的任何參數必須做有效性驗證。說明:忽略參數校驗可能導緻:
page size 過大導緻記憶體溢出
惡意 order by 導緻資料庫慢查詢
任意重定向
SQL 注入
反序列化注入
正則輸入源串拒絕服務 ReDoS
說明:Java 代碼用正則來驗證用戶端的輸入，有些正則寫法驗證普通使用者輸入沒有問題，但是如果攻擊人員使用的是特殊構造的字元串來驗證，有可能導緻死循環的結果。
【強制】禁止向HTML頁面輸出未經安全過濾或未正确轉義的使用者資料。
【強制】表單、AJAX送出必須執行CSRF安全驗證。
說明:CSRF(Cross-site request forgery)跨站請求僞造是一類常見程式設計漏洞。對于存在 CSRF 漏洞的應用/網站，攻擊者可以事先構造好 URL，隻要受害者使用者一通路，背景便在使用者不知情的情況下對資料庫中使用者參數進行相應修改。
【強制】在使用平台資源，譬如短信、郵件、電話、下單、支付，必須實作正确的防重放的機制，如數量限制、疲勞度控制、驗證碼校驗，避免被濫刷而導緻資損。說明:如注冊時發送驗證碼到手機，如果沒有限制次數和頻率，那麼可以利用此功能騷擾到其它使用者，并造成短信平台資源浪費。
【推薦】發貼、評論、發送即時消息等使用者生成内容的場景必須實作防刷、文本内容違禁詞過濾等風控政策。
【強制】表達是與否概念的字段，必須使用is_xxx的方式命名，資料類型是unsigned tinyint（ 1表示是，0表示否）。
說明：任何字段如果為非負數，必須是unsigned。
注意：POJO類中的任何布爾類型的變量，都不要加is字首，是以，需要在＜resultMap＞設定從is_xxx 到Xxx的映射關系。資料庫表示是與否的值，使用tinyint類型，堅持is_xxx的命名方式是為了明确其取 值含義與取值範圍。
正例：表達邏輯删除的字段名is_deleted，1表示删除，0表示未删除。
【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間 隻出現數字。資料庫字段名的修改代價很大，因為無法進行預釋出，是以字段名稱需要慎重 考慮。
說明：MySQL在Windows下不區分大小寫，但在Linux下預設是區分大小寫。是以，資料庫名、表 名、字段名，者環允許出現任何大寫字母，避免節外生枝。
正例： aliyun_admin， rdc_config， level3_name
反例： AliyunAdmin， rdcConfig， level_3_name
【強制】表名不使用複數名詞。
說明：表名應該僅僅表示表裡面的實體内容，不應該表示實體數量，對應于DO類名也是單數形式，符合 表達習慣。
【強制】禁用保留字，如 desc、range、match、delayed 等，請參考 MySQL 官方保留字。
【強制】主鍵索引名為卩匕字段名；唯一索引名為uk_字段名；普通索引名則為idx-字段名。
說明：
pk_ 即 primarykey ；
uk_ 即 unique key ；
idx_ 即 index 的簡稱。
【強制】小數類型為decimal，禁止使用float和double。
說明：在存儲的時候， float 和 double 都存在精度損失的問題，很可能在比較值的時候，得到不正确的結果。如果存儲的資料範圍超過 decimal 的範圍，建議将資料拆成整數和小數并分開存儲。
【強制】如果存儲的字元串長度幾乎相等，使用char定長字元串類型。
【強制】varchar是可變長字元串，不預先配置設定存儲空間，長度不要超過5000，如果存儲長度大于此值，定義字段類型為text，獨立出來一張表，用主鍵來對應，避免影響其它字段索 引效率。
【強制】表必備三字段：id, create_time, update_time。
說明：其中id必為主鍵，類型為bigint unsigned、單表時自增、步長為1。create_time, update_time 的類型均為datetime類型。
【推薦】表的命名最好是遵循“業務名稱_表的作用”。
正例：alipay_task / force_project / trade_config
【推薦】庫名與應用名稱盡量一緻。
【推薦】如果修改字段含義或對字段表示的狀态追加時，需要及時更新字段注釋。
【推薦】字段允許适當備援，以提高查詢性能，但必須考慮資料一緻。備援字段應遵循：
不是頻繁修改的字段。
不是varchar超長字段，更不能是text字段。
不是唯一索引的字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一不變，可在相關聯的表中備援存儲類目名稱，避免關聯查詢。
【推薦】單表行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。 說明：如果預計三年後的資料量根本達不到這個級别，請不要在建立表時就分庫分表。
【參考】将字段很多的表分解成多個表。對于字段比較多的表，如果有些字段的使用頻率很低，可以将這些字段分離出來形成新表，因為當一個表的資料量很大時，會由于使用頻率低的字段的存在而變慢。
【參考】增加中間表。對于需要經常聯合查詢的表，可以建立中間表以提高查詢效率，通過建立中間表，把需要經常聯合查詢的資料插入到中間表中，然後将原來的聯合查詢改為對中間表的查詢，以此來提高查詢效率。
【參考】合适的字元存儲長度，不但節約資料庫表空間、節約索引存儲，更重要的是提升檢 索速度。
正例：如下表，其中無符号值可以避免誤存負數，且擴大了表示範圍。
<col>
對象
年齡區間
類型
位元組
表示範圍
人
150 歲之内
tinyint unsigned
1
無符号值:0 到 255
龜
數百歲
smallint unsigned
2
無符号值:0 到 65535
恐龍化石
數千萬年
int unsigned
4
無符号值:0 到約 42.9 億
太陽
約 50 億年
bigint unsigned
8
無符号值:0 到約 10 的 19 次方
【強制】業務上具有唯一特性的字段，即使是多個字段的組合，也必須建成唯一索引。
說明:不要以為唯一索引影響了 insert 速度，這個速度損耗可以忽略，但提高查找速度是明顯的;另外，即使在應用層做了非常完善的校驗控制，隻要沒有唯一索引，根據墨菲定律，必然有髒資料産生。
【強制】超過三個表禁止join。需要join的字段，資料類型必須絕對一緻;多表關聯查詢時，保證被關聯的字段需要有索引。
說明:即使雙表 join 也要注意表索引、SQL 性能。
【強制】在varchar字段上建立索引時，必須指定索引長度，沒必要對全字段建立索引，根據實際文本區分度決定索引長度即可。
說明:索引的長度與區分度是一對沖突體，一般對字元串類型資料，長度為 20 的索引，區分度會高達90%以上，可以使用 count(distinct left(列名, 索引長度))/count(*)的區分度來确定。
【強制】頁面搜尋嚴禁左模糊或者全模糊，如果需要請走搜尋引擎來解決。
說明:索引檔案具有 B-Tree 的最左字首比對特性，如果左邊的值未确定，那麼無法使用此索引。
【推薦】如果有 order by 的場景，請注意利用索引的有序性。order by 最後的字段是組合索引的一部分，并且放在索引組合順序的最後，避免出現 file_sort 的情況，影響查詢性能。正例:where a=? and b=? order by c; 索引:a_b_c反例:索引如果存在範圍查詢，那麼索引有序性無法利用，如:WHERE a>10 ORDER BY b; 索引 a_b 無法排序。
【推薦】利用覆寫索引來進行查詢操作，避免回表。
說明:如果一本書需要知道第 11 章是什麼标題，會翻開第 11 章對應的那一頁嗎?目錄浏覽一下就好，這個目錄就是起到覆寫索引的作用。正例:能夠建立索引的種類分為主鍵索引、唯一索引、普通索引三種，而覆寫索引隻是一種查詢的一種效果，用 explain 的結果，extra 列會出現:using index。
【推薦】利用延遲關聯或者子查詢優化超多分頁場景。
說明:MySQL 并不是跳過 offset 行，而是取 offset+N 行，然後傳回放棄前 offset 行，傳回 N 行，那當offset 特别大的時候，效率就非常的低下，要麼控制傳回的總頁數，要麼對超過特定門檻值的頁數進行 SQL改寫。
正例:先快速定位需要擷取的 id 段，然後再關聯:SELECT a.* FROM 表 1 a, (select id from 表 1 where 條件 LIMIT 100000,20 ) b where a.id=b.id
【推薦】SQL 性能優化的目标:至少要達到 range 級别，要求是 ref 級别，如果可以是consts 最好。
consts 單表中最多隻有一個比對行(主鍵或者唯一索引)，在優化階段即可讀取到資料。
ref 指的是使用普通的索引(normal index)。
range 對索引進行範圍檢索。
反例:explain 表的結果，type=index，索引實體檔案全掃描，速度非常慢，這個 index 級别比較 range還低，與全表掃描是小巫見大巫。
【推薦】建組合索引的時候，區分度最高的在最左邊。
正例:如果 where a=? and b=? ，如果 a 列的幾乎接近于唯一值，那麼隻需要單建 idx_a 索引即可。說明:存在非等号和等号混合時，在建索引時，請把等号條件的列前置。如:where c>? and d=? 那麼即使 c 的區分度更高，也必須把 d 放在索引的最前列，即索引 idx_d_c。
【推薦】防止因字段類型不同造成的隐式轉換，導緻索引失效。
【參考】建立索引時避免有如下極端誤解:
1) 甯濫勿缺。認為一個查詢就需要建一個索引。
2) 甯缺勿濫。認為索引會消耗空間、嚴重拖慢記錄的更新以及行的新增速度。
3) 抵制惟一索引。認為業務的惟一性一律需要在應用層通過“先查後插”方式解決。
【參考】避免索引沒起作用的情況：
使用LIKE關鍵字的查詢語句。在使用LIKE關鍵字進行查詢的查詢語句中，如果比對字元串的第一個字元為“%”，索引不會起作用。隻有“%”不在第一個位置索引才會起作用。
使用多列索引的查詢語句。MySQL可以為多個字段建立索引。一個索引最多可以包括16個字段。對于多列索引，隻有查詢條件使用了這些字段中的第一個字段時，索引才會被使用。
【參考】對于大的文本字段或者BLOB字段，不要建立索引。
【參考】連接配接查詢的連接配接字段應該建立索引。
【參考】排序字段一般要建立索引。
【參考】分組統計字段一般要建立索引。
【參考】正确使用聯合索引，聯合索引的第一個字段是可以被單獨使用的。例如有如下聯合索引index(userID,dbInstanceID),以下查詢語句是可以使用該索引的，select dbInstanceIdentifier from DBInstance where userID=? ，但是語句select dbInstanceIdentifier from DBInstance where dbInstanceID=?就不可以使用該索引。
【強制】不要使用count(列名)或count(常量)來替代count(*)，count(*)是SQL92定義的标準統計行數的文法，跟資料庫無關，跟 NULL 和非 NULL 無關。
說明:count(*)會統計值為 NULL 的行，而 count(列名)不會統計此列為 NULL 值的行。
【強制】count(distinct col) 計算該列除 NULL 之外的不重複行數，注意 count(distinct col1, col2) 如果其中一列全為 NULL，那麼即使另一列有不同的值，也傳回為 0。
【強制】當某一列的值全是NULL時，count(col)的傳回結果為0，但sum(col)的傳回結果為 NULL，是以使用 sum()時需注意 NPE 問題。
正例:使用如下方式來避免 sum 的 NPE 問題:SELECT IFNULL(SUM(column), 0) FROM table;
【強制】使用ISNULL()來判斷是否為NULL值。
說明:NULL 與任何值的直接比較都為 NULL。
NULL<>NULL 的傳回結果是 NULL，而不是 false。
NULL=NULL 的傳回結果是 NULL，而不是 true。
NULL<>1 的傳回結果是 NULL，而不是 true。
【強制】代碼中寫分頁查詢邏輯時，若count為0應直接傳回，避免執行後面的分頁語句。
【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。
說明:以學生和成績的關系為例，學生表中的 student_id 是主鍵，那麼成績表中的 student_id 則為外鍵。如果更新學生表中的 student_id，同時觸發成績表中的 student_id 更新，即為級聯更新。外鍵與級聯更新适用于單機低并發，不适合分布式、高并發叢集;級聯更新是強阻塞，存在資料庫更新風暴的風險;外鍵影響資料庫的插入速度。
【強制】禁止使用存儲過程，存儲過程難以調試和擴充，更沒有移植性。
【強制】資料訂正(特别是删除、修改記錄操作)時，要先select，避免出現誤删除，确認無誤才能執行更新語句。
【推薦】in操作能避免則避免，若實在避免不了，需要仔細評估in後邊的集合元素數量，控制在 1000 個之内。
【參考】如果有國際化需要，所有的字元存儲與表示，均以 utf-8 編碼，注意字元統計函數的差別。
【參考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日志資源少，但TRUNCATE 無事務且不觸發 trigger，有可能造成事故，故不建議在開發代碼中使用此語句。
說明:TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。
【參考】分解關聯查詢，将一個大的查詢分解為多個小查詢是很有必要的。很多高性能的應用都會對關聯查詢進行分解，就是可以對每一個表進行一次單表查詢，然後将查詢結果在應用程式中進行關聯，很多場景下這樣會更高效，例如：
3
5
6
7
9
10
SELECT * FROM tag
JOIN tag_post ON tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';
分解為：
SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id = 1234;
SELECT * FROM post WHERE post.id in (123,456,567);
【參考】查詢語句應該盡量避免全表掃描，首先應該考慮在Where子句以及OrderBy子句上建立索引，但是每一條SQL語句最多隻會走一條索引，而建立過多的索引會帶來插入和更新時的開銷，同時對于區分度不大的字段，應該盡量避免建立索引，可以在查詢語句前使用explain關鍵字，檢視SQL語句的執行計劃，判斷該查詢語句是否使用了索引。
【參考】應盡量使用EXIST和NOT EXIST代替 IN和NOT IN，因為後者很有可能導緻全表掃描放棄使用索引。
【參考】應盡量避免在Where子句中對字段進行NULL判斷，因為NULL判斷會導緻全表掃描。
【參考】應盡量避免在Where子句中使用or作為連接配接條件，因為會導緻全表掃描。
【參考】應盡量避免在Where子句中使用！=或者<>操作符，因為會導緻全表掃描。
【參考】使用like “%abc%” 或者like “%abc” 同樣也會導緻全表掃描，而like “abc%”會使用索引。
【參考】在使用Union操作符時，應該考慮是否可以使用Union ALL來代替，因為Union操作符在進行結果合并時，會對産生的結果進行排序運算，删除重複記錄，對于沒有該需求的應用應使用Union ALL，後者僅僅隻是将結果合并傳回，能大幅度提高性能。
【參考】應盡量避免在Where子句中使用表達式操作符，因為會導緻全表掃描。
【參考】應盡量避免在Where子句中對字段使用函數，因為會導緻全表掃描。
【參考】Select語句中盡量 避免使用“*”，因為在SQL語句在解析的過程中，會将“”轉換成所有列的列名，而這個工作是通過查詢資料字典完成的，有一定的開銷。
【參考】Where子句中，表連接配接條件應該寫在其他條件之前，因為Where子句的解析是從後向前的，是以盡量把能夠過濾到多數記錄的限制條件放在Where子句的末尾。
【參考】若資料庫表上存在諸如index(a,b,c)之類的聯合索引，則Where子句中條件字段的出現順序應該與索引字段的出現順序一緻，否則将無法使用該聯合索引。
【參考】From子句中表的出現順序同樣會對SQL語句的執行性能造成影響，From子句在解析時是從後向前的，即寫在末尾的表将被優先處理，應該選擇記錄較少的表作為基表放在後面，同時如果出現3個及3個以上的表連接配接查詢時，應該将交叉表作為基表。
【參考】盡量使用>=操作符代替>操作符。例如，如下SQL語句，select dbInstanceIdentifier from DBInstance where id > 3，該語句應該替換成 select dbInstanceIdentifier from DBInstance where id >=4 ，兩個語句的執行結果是一樣的，但是性能卻不同，後者更加 高效，因為前者在執行時，首先會去找等于3的記錄，然後向前掃描，而後者直接定位到等于4的記錄。
【強制】在表查詢中，一律不要使用 * 作為查詢的字段清單，需要哪些字段必須明确寫明。說明:1)增加查詢分析器解析成本。2)增減字段容易與 resultMap 配置不一緻。3)無用字段增加網絡
消耗，尤其是 text 類型的字段。
【強制】POJO類的布爾屬性不能加is，而資料庫字段必須加is_，要求在resultMap中進行字段與屬性之間的映射。
說明:參見定義 POJO 類以及資料庫字段定義規定，在<resultMap>中增加映射，是必須的。在MyBatis Generator 生成的代碼中，需要進行對應的修改。
【強制】不要用resultClass當傳回參數，即使所有類屬性名與資料庫字段一一對應，也需要定義;反過來，每一個表也必然有一個 POJO 類與之對應。
說明:配置映射關系，使字段與 DO 類解耦，友善維護。
【強制】sql.xml 配置參數使用:#{}，#param# 不要使用${} 此種方式容易出現 SQL 注入。
【強制】iBATIS 自帶的 queryForList(String statementName,int start,int size)不推薦使用。說明:其實作方式是在資料庫取到 statementName 對應的 SQL 語句的所有記錄，再通過 subList 取start,size 的子集合。
正例:Map<String, Object> map = new HashMap<>(); map.put("start", start); map.put("size", size);
【強制】不允許直接拿HashMap與Hashtable作為查詢結果集的輸出。說明:resultClass=”Hashtable”，會置入字段名和屬性值，但是值的類型不可控。
【強制】更新資料表記錄時，必須同時更新記錄對應的gmt_modified字段值為目前時間。
【推薦】不要寫一個大而全的資料更新接口。傳入為POJO類，不管是不是自己的目标更新字段，都進行 update table set c1=value1,c2=value2,c3=value3; 這是不對的。執行 SQL時，不要更新無改動的字段，一是易出錯;二是效率低;三是增加 binlog 存儲。
【參考】@Transactional事務不要濫用。事務會影響資料庫的QPS，另外使用事務的地方需要考慮各方面的復原方案，包括緩存復原、搜尋引擎復原、消息補償、統計修正等。
【參考】<isEqual>中的 compareValue 是與屬性值對比的常量，一般是數字，表示相等時帶上此條件;<isNotEmpty>表示不為空且不為 null 時執行;<isNotNull>表示不為 null 值時執行。
【推薦】圖中預設上層依賴于下層，箭頭關系表示可直接依賴，如:開放接口層可以依賴于Web 層，也可以直接依賴于 Service 層，依此類推:
開放接口層:可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行網關安全控制、流量控制等。
終端顯示層:各個端的模闆渲染并執行顯示的層。目前主要是 velocity 渲染，JS 渲染，JSP 渲染，移動端展示等。
Web 層:主要是對通路控制進行轉發，各類基本參數校驗，或者不複用的業務簡單處理等。
Service 層:相對具體的業務邏輯服務層。
Manager 層:通用業務處理層，它有如下特征:
1) 對第三方平台封裝的層，預處理傳回結果及轉化異常資訊。
2) 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。
3) 與 DAO 層互動，對多個 DAO 的組合複用。
DAO 層:資料通路層，與底層 MySQL、Oracle、Hbase 等進行資料互動。
外部接口或第三方平台:包括其它部門 RPC 開放接口，基礎平台，其它公司的 HTTP 接口。
【參考】(分層異常處理規約)在DAO層，産生的異常類型有很多，無法用細粒度的異常進行 catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不需要列印日志，因為日志在 Manager/Service 層一定需要捕獲并列印到日志檔案中去，如果同台伺服器再打日志，浪費性能和存儲。在 Service 層出現異常時，必須記錄出錯日志到磁盤，盡可能帶上參數資訊，相當于保護案發現場。如果 Manager 層與 Service 同機部署，日志方式與 DAO 層處理一緻，如果是單獨部署，則采用與 Service 一緻的處理方式。Web 層絕不應該繼續往上抛異常，因為已經處于頂層，如果意識到這個異常将導緻頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，加上使用者容易了解的錯誤提示資訊。開放接口層要将異常處理成錯誤碼和錯誤資訊方式傳回。
【參考】分層領域模型規約:
DO(Data Object):此對象與資料庫表結構一一對應，通過 DAO 層向上傳輸資料源對象
DTO(Data Transfer Object):資料傳輸對象，Service 或 Manager 向外傳輸的對象。
BO(Business Object):業務對象，由 Service 層輸出的封裝業務邏輯的對象。
AO(Application Object):應用對象，在 Web 層與 Service 層之間抽象的複用對象模型，極為貼近展示層，複用度不高。
VO(View Object):顯示層對象，通常是 Web 向模闆渲染引擎層傳輸的對象。
Query:資料查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。
【強制】定義GAV遵從以下規則:
GroupID 格式:com.{公司/BU }.業務線 [.子業務線]，最多 4 級。
說明:{公司/BU} 例如:alibaba/taobao/tmall/aliexpress 等 BU 一級;子業務線可選。
正例:com.taobao.jstorm 或 com.alibaba.dubbo.register
ArtifactID 格式:産品線名-子產品名。語義不重複不遺漏，先到中央倉庫去查證一下。
正例:dubbo-client / fastjson-api / jstorm-tool
Version:詳細規定參考下方。
【強制】二方庫版本号命名方式:主版本号.次版本号.修訂号
主版本号:産品方向改變，或者大規模 API 不相容，或者架構不相容更新。
次版本号:保持相對相容性，增加主要功能特性，影響範圍極小的 API 不相容修改。
修訂号:保持完全相容性，修複 BUG、新增次要功能特性等。
說明:注意起始版本号必須為:1.0.0，而不是 0.0.1，正式釋出的類庫必須先去中央倉庫進行查證，使版本号有延續性，正式版本号不允許覆寫更新。如目前版本:1.3.3，那麼下一個合理的版本号:1.3.4 或1.4.0 或 2.0.0
【強制】線上應用不要依賴SNAPSHOT版本(安全包除外)。
說明:不依賴 SNAPSHOT 版本是保證應用釋出的幂等性。另外，也可以加快編譯時的打包建構。
【強制】二方庫的新增或更新，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變，必須明确評估和驗證。
說明:在更新時，進行 dependency:resolve 前後資訊比對，如果仲裁結果完全不一緻，那麼通過dependency:tree 指令，找出差異點，進行<exclude>排除 jar 包。
【強制】二方庫裡可以定義枚舉類型，參數可以使用枚舉類型，但是接口傳回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。
【強制】依賴于一個二方庫群時，必須定義一個統一的版本變量，避免版本号不一緻。說明:依賴 springframework-core,-context,-beans，它們都是同一個版本，可以定義一個變量來儲存
版本:${spring.version}，定義依賴的時候，引用該版本
【強制】禁止在子項目的pom依賴中出現相同的GroupId，相同的ArtifactId，但是不同的Version。
說明:在本地調試時會使用各子項目指定的版本号，但是合并成一個 war，隻能有一個版本号出現在最後的 lib 目錄中。可能出現線下調試是正确的，釋出到線上卻出故障的問題。
【推薦】底層基礎技術架構、核心資料管理平台、或近硬體端系統謹慎引入第三方實作。
【推薦】所有pom檔案中的依賴聲明放在<dependencies>語句塊中，所有版本仲裁放在<dependencyManagement>語句塊中。說明:<dependencyManagement>裡隻是聲明版本，并不實作引入，是以子項目需要顯式的聲明依賴，version 和 scope 都讀取自父 pom。而<dependencies>所有聲明在主 pom 的<dependencies>裡的依賴都會自動引入，并預設被所有的子項目繼承。
【推薦】二方庫不要有配置項，最低限度不要再增加配置項。
【參考】為避免應用二方庫的依賴沖突問題，二方庫釋出者應當遵循以下原則:
精簡可控原則。移除一切不必要的 API 和依賴，隻包含 Service API、必要的領域模型對象、Utils類、常量、枚舉等。如果依賴其它二方庫，盡量是 provided 引入，讓二方庫使用者去依賴具體版本号;無 log 具體實作，隻依賴日志架構。
穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪裡，都需要能友善查到。除非使用者主動更新版本，否則公共二方庫的行為不應該發生變化。
【推薦】高并發伺服器建議調小TCP協定的time_wait逾時時間。
說明:作業系統預設 240 秒後，才會關閉處于 time_wait 狀态的連接配接，在高并發通路下，伺服器端會因為處于 time_wait 的連接配接數太多，可能無法建立新的連接配接，是以需要在伺服器上調小此等待值。
正例:在 linux 伺服器上請通過變更/etc/sysctl.conf 檔案去修改該預設值(秒):net.ipv4.tcp_fin_timeout = 30
推薦】調大伺服器所支援的最大檔案句柄數(FileDescriptor，簡寫為fd)。說明:主流作業系統的設計是将 TCP/UDP 連接配接采用與檔案一樣的方式去管理，即一個連接配接對應于一個fd。主流的 linux 伺服器預設所支援最大 fd 數量為 1024，當并發連接配接數很大時很容易因為 fd 不足而出現“open too many files”錯誤，導緻新的連接配接無法建立。建議将 linux 伺服器所支援的最大句柄數調高數倍(與伺服器的記憶體數量相關)。
【推薦】線上上生産環境，JVM的Xms和Xmx設定一樣大小的記憶體容量，避免在GC 後調整堆大小帶來的壓力。
【參考】伺服器内部重定向使用forward;外部重定向位址使用URL拼裝工具類來生成，否則會帶來 URL 維護不一緻的問題和潛在的安全風險。
【推薦】給 JVM 環境參數設定-XX:+HeapDumpOnOutOfMemoryError 參數，讓 JVM 碰到OOM 場景時輸出 dump 資訊。
說明:OOM 的發生是有機率的，甚至相隔數月才出現一例，出錯時的堆内資訊對解決問題非常有幫助。
【強制】存儲方案和底層資料結構的設計獲得評審一緻通過，并沉澱成為文檔。
說明：有缺陷的底層資料結構容易導緻系統風險上升，可擴充性下降，重構成本也會因曆史資料遷移和系 統平滑過渡而陡然增加，是以，存儲方案和資料結構需要認真地進行設計和評審，生産環境送出執行後，需要進行double check。
正例：評審内容包括存儲媒體選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或字段之間的辯證關系、字段名稱、字段類型、索引等；資料結構變更（如在原有表中新增字段） 也需要進行評審通過後上線。
【強制】在需求分析階段，如果與系統互動的User超過一類并且相關的User Case超過5 個，使用用例圖來表達更加清晰的結構化需求。
【強制】如果某個業務對象的狀态超過3個，使用狀态圖來表達并且明确狀态變化的各個觸 發條件。
說明：狀态圖的核心是對象狀态，首先明确對象有多少種狀态，然後明确兩兩狀态之間是否存在直接轉換 關系，再明确觸發狀态轉換的條件是什麼。
正例：淘寶訂單狀态有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀态之間是不可能有直接轉換關系的。
【強制】如果系統中某個功能的調用鍊路上的涉及對象超過3個，使用時序圖來表達并且明 确各調用環節的輸入與輸出。
說明：時序圖反映了一系列對象間的互動與協作關系，清晰立體地反映系統的調用縱深鍊路。
【強制】如果系統中模型類超過5個，并且存在複雜的依賴關系，使用類圖來表達并且明确 類之間的關系。
說明：類圖像建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻Z空間大樓，肯定需要詳細 的施工圖。
【強制】如果系統中超過2個對象之間存在協作關系，并且需要表示複雜的處理流程，使用 活動圖來表示。
說明：活動圖是流程圖的擴充，增加了能夠展現協作關系的對象泳道，支援表示并發等。
【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。 反例：使用者在淘寶付款過程中，銀行扣款成功，發送給使用者扣款成功短信，但是支付寶入款時由于斷網演 練産生異常，淘寶訂單頁面依然顯示未付款，導緻使用者投訴。
【推薦】類在設計與實作時要符合單一原則。
說明：單一原則最易了解卻是最難實作的一條規則，随着系統演進，很多時候，忘記了類設計的初衷。
【推薦】謹慎使用繼承的方式來進行擴充，優先使用聚合/組合的方式來實作。
說明：不得已使用繼承的話，必須符合裡氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現， 比如，"把錢交出來"，錢的子類美元、歐元、人民币等都可以出現。
【推薦】系統設計時，根據依賴倒置原則，盡量依賴抽象類與接口，有利于擴充與維護。
說明：低層次子產品依賴于高層次子產品的抽象，友善系統間的解耦。
【推薦】系統設計時，注意對擴充開放，對修改閉合。
說明：極端情況下，傳遞線上生産環境的代碼都是不可修改的，同一業務域内的需求變化，通過子產品或類的擴充來實作。
【推薦】系統設計階段，共性業務或公共行為抽取出來公共子產品、公共配置、公共類、公共方法等，避免出現重複代碼或重複配置的情況。
說明：随着代碼的重複次數不斷增加，維護成本指數級上升。
【推薦】避免如下誤解：靈活開發=講故事+編碼+釋出。
說明：靈活開發是快速傳遞疊代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點 上的必要設計和文檔沉澱是需要的。
反例：某團隊為了業務快速發展，靈活成了産品經理催進度的借口，系統中均是勉強能運作但像面條一樣的代碼，可維護性和可擴充性極差，一年之後，不得不進行大規模重構，得不償失。
【參考】系統設計主要目的是明确需求、理順邏輯、後期維護，次要目的用于指導編碼。 說明：避免為了設計而設計，系統設計文檔有助于後期的系統維護和重構，是以設計結果需要進行分類歸 檔儲存。
【參考】設計的本質就是識别和表達系統難點，找到系統的變化點，并隔離變化點。
說明：世間衆多設計模式目的是相同的，即隔離系統變化點。
【參考】系統架構設計的目的：
确定系統邊界。确定系統在技術層面上的做與不做。
确定系統内子產品之間的關系。确定子產品之間的依賴關系及子產品的宏觀輸入與輸出。
确定指導後續設計與演化的原則。使後續的子系統或子產品設計在規定的架構内繼續演化。
确定非功能性需求。非功能性需求是指安全性、可用性、可擴充性等。
【參考】在做無障礙産品設計時，需要考慮到：
所有可互動的控件元素必須能被tab鍵聚焦，并且焦點I順序需符合自然操作邏輯。
用于登陸校驗和請求攔截的驗證碼均需提供圖形驗證以外的其它方式。
自定義的控件類型需明确互動方式
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)