1. 為什麼需要 Code Review？
Code Review（代碼評審）是日常開發中必不可少的步驟，但是一些開發者重視不夠，沒有體驗到Code Review的好處。覺得自己發起的Code Review同僚沒有認真傾聽，同僚發起的Code Review又在耽誤自己的開發時間。今天一燈就跟一起總結一下Code Review的好處。
1.1 統一代碼風格
團隊内代碼風格的統一，可以增加代碼的可讀性，便于繼任者快速上手。
你看到下面的換行，是什麼感覺？
public class UserService {
@Autowired
private UserDao userDao;
/**
* 不規範的換行
*/
public User getUserById(Long userId)
{
return userDao.getUserById(userId);
}
} 1.2 提前發現bug
每個人功能是有限的，不可能考慮的很全面，對業務的了解也不同。其他人可以站在另一個角度，幫助潛在的bug，規避線上問題。
1.3 提高代碼品質
有些開發者以完成任務為目的，完全不考慮架構風格，老子就是一把梭。接口層直接調用到資料層，代碼調用混亂，重複編寫。一個方法幾百行，一個類幾千行，寫完第二天自己也看不懂了。
作為程式員還是需要對代碼品質有追求的，很多招聘要求面試者有代碼潔癖。雷軍說自己寫的代碼像詩一樣優美，咱們普通開發者也要向大佬看齊。
有些經典書籍有助于提升代碼品質，像是《重構：改善既有代碼的設計》、《代碼整潔之道》、《代碼大全》等。
1.4 促進知識共享
每次做Code Review，都是在做知識分享、交流學習。梳理自己實作方案，學習别人的架構風格、業務思路，對自己的技術和業務了解也是一種提高。也有助于培養團隊内的技術氛圍。
1.5 增加業務學習
了解業務上增加了什麼新功能，對現有業務的影響是什麼，更有助于團隊成員之間溝通與協作。
2. Code Review 基本原則
在進行 Code Review 時，應遵循以下基本原則，以確定過程的高效和順利：
2.1 以交流學習為目的
幫助同僚做Code Review的目的是互相交流學習，而不是抓住同僚的錯誤不放，炫耀自己的技術有多強。團隊成員之間應該保持開放和積極的态度，互相學習和進步。
2.2 保持客觀和專業
保持客觀和專業的态度，評審代碼的品質和符合規範的程度，而不是評價送出者本人。指出任何錯誤的時候，都要在對方可接受的範圍内。
2.3 及時回報結果
Code Review 應該是一個及時和持續的過程。審查者應在收到代碼送出後盡快進行審查，以避免延誤項目進度。同時，送出者在收到回報後應及時進行修改和回應，以確定問題得到及時解決。審查者在确認修改後，應及時準許代碼合并，以保持開發流程的高效運轉。
3. Code Review 時機
發起 Code Review 的時機，最好是在需求提測前，這樣可以保證Review後做的代碼變更，可以被測試覆寫到。
有些開發者喜歡在上線前發起 Code Review ，這樣是不對的。誰敢給你做 Code Review ，給你提了稽核建議，你也沒辦法修改，馬上就要上線了。
4.Code Review 注意事項
在進行 Code Review 時候，稽核者往往不知道從哪下手。可以關注以下幾個方面，以提高審查的效果和品質。
4.1 關注代碼風格
團隊内部最好遵守相同的代碼規範，比如：變量命名、常量定義、枚舉值定義、代碼格式、日期格式化工具、異常處理、注釋規範、傳參和響應資料包裝、建表規約等，參考《阿裡Java開發手冊》。
4.2 單元測試要求
單元測試是開發者最容易忽略的問題，通常要求新增代碼的單測覆寫率至少達到70%。寫好單元測試用例可以幫助開發者提高代碼品質，減少低級bug，減少調試時間。
4.3 符合架構規範
代碼是否符合常見的架構規範，比如：單一職責原則、開閉原則、是否存在跨層調用、是否有重複邏輯、領域邊界劃分是否合理等。
4.4 代碼健壯性
通常隻有20%的代碼用來實作核心邏輯，而80%的代碼用來保證程式安全。
實作了核心邏輯之後，代碼的健壯性也是一個不可忽略的名額。可以關注以下幾個方面：
- 是否有判空和異常傳參校驗
- 邏輯邊界是否完整
- 是否存線上程安全問題
- 是否存在并發調用問題
- 是否需要支援幂等
- 是否存在記憶體洩露風險
- 是否有資源邊界限制
- 是否存在資料一緻性問題
- 是否需要增加限流、熔斷、降級等保護機制
- 是否需要相容舊邏輯、舊版本
4.5 接口性能問題
接口性能也是需要重點關注的問題，可以關注以下幾個方面：
- 是否存在循環調用（接口、資料庫），能否改成批量處理
- 調用外部接口是否設定合理的逾時時間
- 對外開放的接口，是否預估調用量？是否有保護機制（限流、熔斷、降級）？
- 是否需要增加本地緩存、分布式緩存、多線程、消息隊列
- 列印日志是否過多
4.6 資料安全問題
表現形式為：使用者可以通路或者操作不屬于自己管理範圍内的接口或者接口的資料。
需要關注接口是否需要登入态、參數簽名的校驗，是否有橫向越權和縱向越權的問題，對外暴露的資料需要脫敏處理。