阿里的《Java開發手冊》距離上次發佈已經過去了 10 個月了，而這次發佈也增加了很多幹貨內容，比如：新增 34 條規約，修改描述 90 處，其中錯誤碼規則更是第一次提出完整的解決方案，發佈日誌如下圖所示：
回顧阿里巴巴開發手冊1.4.0版
一、編程規約
二、異常日誌
三、單元測試
四、安全規約
五、MySQL數據庫
六、工程結構
七、設計規約
終極版
一、編程規約
二、異常日誌
三、單元測試
四、安全規約
五、MySQL數據庫
六、工程結構
新增內容概覽
本次更新主要更新的內容有：
- 新增了錯誤碼規範；
- 擴充了日期（閏年、閏月等）處理方案；
- 表別名規範；
- 三目運算符規範等。
接下來我們來看這些新增內容的具體含義。
1.錯誤碼規範
之前版本中是沒有關於「錯誤碼」的整體說明的，而這個版本增加了很大的篇幅，來把這個前後端配合的重要環節「錯誤碼」部分，做了詳細的規範和說明，可謂非常的香，具體規範如下：
- 【強制】錯誤碼的制定原則：快速溯源、簡單易記、溝通標準化。
- 【強制】錯誤碼不體現版本號和錯誤等級信息。
- 【強制】全部正常，但不得不填充錯誤碼時返回五個零：00000。
- 【強制】錯誤碼爲字符串類型，共 5 位，分成兩個部分：錯誤產生來源 + 四位數字編號。
說明：錯誤產生來源分爲 A/B/C：
- A：表示錯誤來源於用戶，比如參數錯誤，用戶安裝版本過低，用戶支付超時等問題；
- B：表示錯誤來源於當前系統，往往是業務邏輯出錯，或程序健壯性差等問題；
- C：表示錯誤來源於第三方服務，比如 CDN 服務出錯，消息投遞超時等問題；四位數字編號從 0001 到 9999，大類之間的步長間距預留 100，詳情可見《Java開發手冊》正文。
2.擴充了日期處理方案
一個寫死爲 365 天的年份天數，在閏年裏讓大家嚐盡了悲傷痛楚，比如，緩存有效期 = 3652460*60 秒，結果提前一天所有緩存同時失效，高併發訪問時數據庫就跪了。
【強制】不要在程序中寫死一年爲 365 天，避免在公曆閏年時出現日期轉換錯誤或程序邏輯錯誤。
正例：
反例：
3.表別名規範
【強制】對於數據庫中表記錄的查詢和變更，只要涉及多個表，都需 表名）進行限定。 說明：對多表進行查詢記錄、更新記錄、刪除記錄時，如果對操作列沒有限定表的別名（或表名），並且 操作列在多個表中存在時，就會拋異常。 正例：select t1.name from table_first as t1 , table_second as t2 where t1.id=t2.id;
反例：在某業務中，由於多表關聯查詢語句沒有加表的別名（或表名）的限制，正常運行兩年後，最近在 某個表中增加一個同名字段，在預發佈環境做數據庫變更後，線上查詢語句出現出 1052 異常：Column 'name' in field list is ambiguous。
【推薦】SQL 語句中表的別名前加 as，並且以 t1、t2、t3、...的順序依次命名。 說明：
- 別名可以是表的簡稱，或者是根據表出現的順序，以 t1、t2、t3 的方式命名。
- 別名前加 as 使別名更容易識別。 正例：select t1.name from table_first as t1, table_second as t2 where t1.id=t2.id;
4.三目運算符規範
原來在三目運算符中：
condition ? 表達式1 : 表達式2
表達式 1 和 2 在涉及算術計算或數據類型轉換時，會觸發自動拆箱。拆箱操作本來沒有問題，但是當其中的操作數爲 null 值時，一個大大的 NPE 就砸到了我滴臉上，如下代碼所示：
注意：a*b 的結果是 int 類型，那麼 c 會強制拆箱成 int 類型，拋出 NPE 異常。
【強制】三目運算符 condition? 表達式 1 : 表達式 2 中，高度注意表達式 1 和 2 在類型對齊時，可能拋出因自動拆箱導致的 NPE 異常。
說明：以下兩種場景會觸發類型對齊的拆箱操作：
- 表達式 1 或表達式 2 的值只要有一個是原始類型。
- 表達式 1 或表達式 2 的值的類型不一致，會強制拆箱升級成表示範圍更大的那個類型。
阿里巴巴內部開發手冊—1.4.0版+終極版
內部開發手冊
阿里巴巴內部PPT、PDF及JD億級流量架構
靈魂十三問
阿里內部PPT、PDF及開發手冊1.4.0版+終極版+泰山版感興趣的關注我私信回覆【架構書籍】即可免費領取