關注程式碼品質：Code Review 的技巧與實踐

引言#

Code Review 是軟體開發過程中一項至關重要的任務。它可以幫助我們發現程式碼中的問題、提高程式碼品質，並為團隊提供一個共享知識的機會。本文將詳細介紹 Code Review 的相關經驗與技巧，希望能為大家提供一個可用的參考。

Code Review 的目標#

在進行 Code Review 之前，我們需要明確這一過程的主要目標：

1. 統一程式碼風格#

程式碼風格的統一對於提高程式碼的可讀性和可維護性具有重要意義。通過 Code Review，我們可以確保團隊成員遵循相同的編碼規範，使程式碼更加整潔、統一。

2. 促進團隊技能提升和溝通#

Code Review 不僅能夠促進團隊成員之間的知識共享，還可以倒逼 Reviewer 深入理解程式碼和業務邏輯。在 Review 過程中，我們可以向其他團隊成員請教問題、分享技巧，提高整個團隊的技術水平。

3. 提高程式碼品質和減少潛在風險#

通過 Code Review，我們可以發現程式碼中潛在的問題，進一步提高程式碼品質。以下是一些可能在 Code Review 過程中發現的問題類型：

邊界情況：確保程式碼能夠正確處理各種邊界輸入，例如空值、特殊字符等。
過度封裝或偷懶不封裝：合理的封裝能夠提高程式碼的可讀性和可維護性。我們需要在 Code Review 過程中關注是否存在過度封裝或應該封裝但未封裝的情況。
可能忽略的公共組件：在專案中，我們可能忽略了某個已存在的公共組件，也可能忽略了我們的業務與其他成員的業務存在潛在的公用組件。Code Review 可以幫我們再檢查一次，減少程式碼重複。

實際操作#

在明確了 Code Review 的目標之後，接下來我們將詳細介紹實際操作中的流程和技巧。

Git 操作#

在進行 Code Review 時，我們需要遵循一定的 Git 分支操作流程：

從 master 分支切出需求分支，例如 release/v1.0：

git checkout -b release/v1.0

開發者從需求分支（如 release/v1.0）切出功能分支，例如 feat/v1.0-sub-module：

git checkout -b feat/v1.0-sub-module

功能分支開發完畢後，向需求分支發起 Merge Request（MR）。在發起 MR 時，應提供以下信息（可以使用 MR Template 統一管理）：

這個 MR 解決了什麼問題：說明為什麼需要這個 MR，可以附上需求講解、文件等。
這個 MR 修改了什麼：簡要介紹增加、修改、刪除了哪些模組程式碼。
是否可能影響其他功能模組。

注意事項：

一個分支對應一個 MR。
不要在一個分支上發起多次 MR。
合併 MR 時，勾選 Squash commits 和 Delete branch 選項，並使用 Fast-forward merge。使用 rebase 來處理衝突。

MR 合併後，在本地批量刪除分支：

git fetch --prune && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D

::: warning
該命令會比對本地分支與遠程分支的差異，刪除對應遠程分支不存在的本地分支。

這個操作比較危險，建議僅在有多個待刪除分支時使用。
:::

通知 Reviewer#

在發起 MR 後，及時通知 Reviewer。Reviewer 可以將相應記錄設為待辦事項，以便於跟踪。

Reviewer 的工作#

收到通知後，Reviewer 必須在 1 個工作日內完成 Review。理想情況下，應立即處理，除非有其他緊急任務。為了確保 Review 過程的高效，我們需要注意以下幾點：

Committer 應控制 MR 的大小，讓 Reviewer 在 20 分鐘內可以完成 Review。具體要求如下：
- 一次 MR 的工作量控制在兩個工作日以內，最好一個
- 不超過 8 個文件
- 不超過 500 行程式碼
- 如果有特殊情況產生了大 MR，提前與 Reviewer 預約時間
- 盡量讓 MR 主題單一
- 可以跟 reviewer 當面講解需求背景以及交互來提速
在 Review 過程中，參照以下 checklist：
- 命名規範
- 目錄規範
- 程式碼規範
- 單詞拼寫檢查
- 重用邏輯檢查
- 可複用組件檢查
- TypeScript 型別檢查（使用 any 或 as 必須加註釋）
- 註釋檢查（當你看不懂程式碼時可能是程式碼需要優化，也可能是業務邏輯複雜，這時需要提示開發者加適當的註釋）
- 其他團隊編碼規範
盡量使用自動化工具減少人力成本，例如 ESLint、Prettier、Stylelint 等。

額外的注意點#

在進行 Code Review 時，我們需要注意以下幾點，以提高整個流程的效果和效率：

複雜的需求需要先進行方案設計，並邀請你的 reviewer 先溝通一次：這可以避免在開發好幾天後出現問題時，改造的時間成本過高。
針對複雜或重要的邏輯加測試：可以先從簡單的檢測 JavaScript 和 TypeScript 方法開始，逐步養成這個習慣。
如果一個 MR 來回溝通超過 3 次則請求第三方介入：確認雙方意見都已表達且相互理解，仍未達成一致時立即尋求第三方幫助。有較大爭議的可在周會上提出小組確定規範後記入程式碼規範。
評估工期時適當留一些時間給 Code Review：尤其是剛開始 review 問題可能比較多，會佔用較長時間。
聯調及測試期間一般 MR 都不大且程式碼比較容易 review：不用擔心 Code Review 耽誤 bug fix 進度。
對於在 MR 裡遇到的不能及時解決的問題：為了不耽誤後續 MR 的合併，可以先用 issue 記錄問題並關聯到 MR，在後期單獨處理 issue。
Review 不是找茬，盡可能用委婉的語氣：
- 使用諸如 "我覺得"、"可以這樣" 等詞語；
- 避免使用 "你 xxx"、"錯誤" 等詞語；
- 看到好程式碼不要吝嗇讚美；
- 在 Comment 中盡量留下建議的 Code Example，程式碼往往比語言直觀得多。
預先 review 一下自己的 MR：在提交給其他人 review 之前，確保自己已經對程式碼進行了仔細檢查。
程式碼是給人看的而不是機器：編寫易於理解和維護的程式碼，以便其他團隊成員可以更好地進行 Code Review 和後期維護。

Haydenull