如何建立和執行 Code Review
Published
好處
可以成為工程師
壞處
不能成為工程師
前置作業
在開始進行 Code Review 之前，可以先按照以下步驟來進行
建立檢查清單
建立一個檢查清單可以列出三項(必要清單、專案清單、邏輯清單)，以下只是範例。
必要清單
每個 PR 都一定要符合的項目
- Branch 命名 和 Commit haed 是否符合格式
- Commit body 描述符合格式
- Coding style 是否符合規範
- 檔案結構和命名是否符合規範
- PR/MR 的 Title 和 Description 是否符合規範
- 是否包含測試資訊和腳本，和測試後的截圖或報告
- 相關文件是否更新
- 是否包含了金鑰或密碼敏感資訊
專案項目
各專案一定要符合的項目，例如 Website、APP、Backend、SRE 的專案各自需要注意的規範
- Website：
- 是否包含符合 UI 設計
- RWD 是否通過
- APP：
- 是否符合 UI 設計
- OS 的版本或平台是否驗證
- Backend
- API 文件是否編寫並更新
- 更動 Database Schema 的話是否有做版本控制腳本
- SRE
- 是否有更新架構圖
- 調整後的成本預估
邏輯清單
用於 Reviewer 在 Review 時應該要注意的地方
- 是否 Thread-safe
- 是否有 Race condition 的 Side effect
- 效能上是否更好的作法
- 邏輯上是否符合 Ticket 要求
- 是否跟文件描述相同
- 修改範圍是否太多
- 測試是否符合：獨立性、唯一性、符合 Ticket 所需、是否有沒思考到的測試情境
- 檢查程式的邏輯、可讀性、模組化、複用性、錯誤處理
規劃流程
前置的三項清單都列完後，開始就是規劃流程。一般 Reivew 上有以下執行階段
- Pre-commit hook / Pre-push Git hook
- PR created(CI Pipeline)
- Reviewer starts review
第一步先區分出清單上，哪些可以自動化，哪些不行。而自動化的項目又各自要在哪些階段來執行。
- Pre-commit hook / Pre-push Git hook：
- Linter 檢查 Coding Style
- Regex express 檢查 Branch 命名和 Commit
- CI Pipeline：
- SonarQube 弱點掃描
- Test 腳本執行
人工審核
這一步開始就是 Reviewer 的工作了，在這一步將無法自動化的項目來檢查。因為大部分的條件都已經檢查，因此在這一階段應該更專注在邏輯上。
建議
- 可以的話跟作者一起審核，節省來回討論的時間。或是善用 IDE plugin 或通訊軟體，將 PR 的事件串接起來有更快速的通知
- 每個 PR 拆分的越小越好，因為相關的檔案越多，要考慮影響就更多。要釐清和審核上的時間也相對的越長。如果無法的話，也可以嘗試拆分成不同的 commit。例如文件修改、測試、邏輯更新各自為不同的 commit
- 多人審核，可以給不同部門的人審核。例如資安部門、SRE。不同領域的人來審閱