代碼CR模板 - 田野放空

代碼 CR 模板#

基礎篇#

編碼風格遵循阿里巴巴 Java 開發手冊
大型複雜流程程序必須提供流程圖、時序圖
1. 被 cr 同學在 cr 開始需簡單敘述項目大小及其背景，複雜流程需要 cr 實現邏輯是否 match 技術方案，減少實現跟技術方案的 gap
業務邏輯劃分是否合理，是否耦合
1. 業務邏輯涉及領域的邏輯，明顯或耦合的業務邏輯建議拆分
代碼編碼邏輯是否清晰
1. 被 cr 同學需要講清楚主幹邏輯
合理有效的註釋
1. 邏輯複雜的代碼或 cr 有疑問的邏輯，要求補充合理有效的註釋
是否存在冗余代碼
1. 多餘或者沒有引用的代碼建議刪除
是否存在潛在 NPE
1. NPE 是日常工作必出現的 bug
  
  上下文字段使用不判空，getXX () 操作，基本類型拆箱，需要防禦式判斷或 Optional
日誌打印規範
1. 強制使用佔位符進行日誌打印，因為字符串拼接會使用 StringBuilder 的 append () 方式，有一定的性能損耗
  
  logger.info("are u ok : oid 1", oid);
  logger.info("are u ok : oid 1", oid);
有沒有 maven 依賴衝突
- 很多時候詭異的運行時 bug，往往由於依賴衝突導致，cr 建議確認是否有 pom 變更
資源釋放
- 無論是網絡 io 還是文件 io、資源釋放的邏輯需要被 cr 到
統一錯誤碼
- 禁止統一返回 - 1、500 等錯誤碼，最好定義枚舉，方便追溯問題
異常的處理
- 出現異常的地方需要確認是否需要進行一下操作：直接返回、拋出異常、重試處理、恢復處理、熔斷處理、降級處理、關閉業務

初級篇#

數據庫索引設計是否合理、是否生效
- 被 cr 同學要講清楚設計索引的原因以及效果
代碼是否可以使用設計模式或者設計模式是否過度設計
- if/else 過多或者場景分發類邏輯，建議采用策略模式
- 不建議小的需求、進行複雜的繼承抽象邏輯，良好的設計是模型的合理
- 不建議引入複雜的框架解決簡單問題，有些同學熱衷於一個框架搞定所有架構 (比如 ddd cola)，毕竟代碼的歷史性、複雜度框架是評估不了的、好的業務框架腳手架更傾向於用這種思想解決問題，而非照搬
中間件使用是否最佳實踐
- 比如 mq 消費是否正確 ack、還是需要重試、還是丟棄
- 比如 redis 是否存在大 key 設計、需要進行合理設計
- 比如 es 查詢是否設置合理超時時間
線程池使用、參數是否正確、是否業務隔離
- 是否使用公司框架或 jdk 自帶帶參線程池構建方法
- 線程數、隊列大小是否配置合理
- 多業務或調用方、是否配置隔離線程池
如果使用鎖，鎖範圍、粒度是否合適
- 分布式鎖的鎖區間需要 check 是否影響其他
事務處理：是否需要事務，事務是否生效
- 持久化操作是否沒有加事務
- 類內部調用是否導致事務沒生效

進階篇#

性能優化#

需要緩存的地方是否添加緩存
- 比如依賴的外部接口性能差、添加合適的緩存解決查詢問題
樂觀鎖代替悲觀鎖
多接口聚合采用多線程加速

一致性#

幂等性#

基於狀態的幂等
- 基於狀態，也就是是說調用該接口，會導致狀態變化，如果狀態已經發生變化，那麼就直接返回
  之前的結果即可
基於某個 key 的幂等
- 通常使用單獨的字段來綁定或者日誌表來記錄，如果存在，直接返回

重試#

接口調用失敗重試
1. 存在寫操作的的外部接口建議不重試、讓外部重新發起請求如果需要發起重試、
2. check 提供的接口支持幂等返回