0. 前言

本文來自《阿里巴巴Java開發手冊》，以下內容均根據自己偏好摘抄、總結、分享。

1. 編程規約

• 包名單數，類名復數。例如：com.tao.util.JsonUtils.java
• 不要使用一個類來維護所有的常量，要根據功能進行分類。例如：
  • 緩存常量類：CacheConsts
  • 配置常量類：ConfigConsts
• Object的equals容易拋出空指針，推薦使用 java.util.Objects#equals：

  public static boolean equals(Object a, Object b) {
      return (a == b) || (a != null && a.equals(b));
  }
  

• String#split 會丟棄后面的空白。例如："1,2,,," => ["1","2"]
• Collections#emptyList()/singletonList() 都是不可變對象，不能添加刪除元素。
• ArrayList 中 subList 返回的內部類 SubList，并不是 ArrayList，而是 ArrayList 的一個視圖，操作 subList，ArrayList 數據也會跟著變化。
• 如果 if 語句條件復雜，可以復制給一個變量。
• 批量操作接口入參需要進行保護，超過多少條不進行處理。
• 參數校驗：
  • 很少進行執行的，參數校驗也不會耗費多少性能。
  • 執行時間開銷大的，執行時間長，盡可能保證別執行一半出錯了。
  • 需要穩定性高的，如銀行系統，必須進行參數校驗，不穩定，損失的都是真金白銀。
  • 對外提供的開放接口，不知道別人會給你傳過來什么數據，臟數據不處理，你的系統就成垃圾場了。
  • 權限敏感接口，參數校驗失敗，出現刪庫跑路。

2. 異常日志

• 細粒度處理異常，不要 catch 一大段（catch 一大段，你很難知道什么地方拋出了異常，從而很難進行正確的異常處理）。
• 可以使用 warn 記錄用戶輸入參數的錯誤情況，如非必要不要再此場景打出 error 級別，error 只記錄系統邏輯出錯、異常等重要的錯誤信息。（比如用戶數據參數錯誤，你給了"xxx 參數不正確"的返回，此場景不需要打 error，用戶能根據錯誤提示進行修正。）

3. 單元測試

• 對數據庫的操作應該設置回滾操作，單元測試不應該污染數據庫，且單元測試的數據應該使用單元測試的標識，方便區分。

4. 安全規約

• 用戶請求傳入的任何參數必須做有效的驗證：
  • pageSize 過大容易導致內存溢出。
  • 惡意使用 orderBy 導致慢查詢。
  • 短信、郵件、電話、下單、支付等場景必須實現正確的防重放機制（公司的短信都是先發送到MQ，然后消費者去消費，某次消費者邏輯出現異常，導致消息被重復消費好幾遍，還好消費邏輯有校驗是否發送過短信，否則一個用戶會發送好多遍短信）。

5. MYSQL

建表規約

• 表達是否概念的字段必須使用 is_xxx 的方式，類型為 unsigned tinyint（1是0否）（is_xxx 仁者見仁智者見智）。
• 表名不使用復數的形式。
• 單表超過500萬才建議分庫分表。

索引規約

• 業務上具有唯一特性，即使多個字段，也必須建成唯一索引。
• 頁面搜索禁止全模糊或左模糊（因為大多數情況，這倆不走索引）。
• 建組合索引，區分度高的放左邊。

語句

• count(*) 統計null行，count(列名) 不統計null行。
• 使用 ISNULL 判斷是不是null值。
• 分頁邏輯，如果 count=0 直接返回，避免執行后面的分頁語句。
• in 后面的集合元素的個數，最好控制在1000內。
• 不要寫大而全的數據更新接口。
• @Transactionanl 事務不要濫用，事務會影響數據庫的QPS。使用事務要考慮，緩存回滾、消息補償，統計修正等。

6. 工程結構

• DO 與數據庫表一一對應。
• DTO：service向外傳輸的對象。
• BO：由service輸出的封裝業務邏輯的對象。
• Query參數超過2個，需要進行封裝。
• 二方庫：
  • JSON：fastjson
  • MD5：commons-codec
  • 數據操作：ArraysUtils
  • 集合操作：CollectionsUtils

7. 總結

以上為看書總結自認為有用的部分，推薦閱讀原書。