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