背景
這是一個持續了近兩年多時間的項目，項目由最開始只有我一個人，到後來陸陸續續一共有 8 個同學先後給項目貢獻過代碼。如今代碼量已經達到了近 13W+ 行代碼，算的上是個不小的前端項目了。
代碼統計
兩年多的時間裏，大家都是間接的接手或者被接手彼此的代碼。 由於早期同時參與的時候最多也就 2 個同學，Code Review 這種事情似乎就顯得多餘了。不過在大概過了一年多之後，項目業務複雜度和代碼量已經達到了一定規模，而此時已經有 5，6 個不同工作背景的同學參與過這個項目了。此時項目逐漸暴露出來一些工程問題擺在眼前：
- 已完成的功能模塊經常容易改出新問題
- 重複的 API, 模塊封裝
- 奇怪的框架使用方法
- 代碼質量參差不齊
- 悶頭開發，對彼此的工作（代碼）並不熟悉，缺少交流
Code Review 的阻礙 & 疑慮
由於之前瞭解到的 Code Review 的信息都是比較負面的，所以在團隊準備開始加上這個環節時還是有很多疑慮的：
- 迭代節奏緊迫（時間擔憂）
- 需求變更頻繁
- 形式主義，增加工作量，沒有太大意義
通過在網上搜索相關信息，我發現大家遇到的問題和疑慮無外乎這麼幾點。很多團隊的項目時間都非常緊張，功能都做不完，感覺代碼審查太浪費時間了。還有很多的情況是做着做着就淪爲了形式主義, 我搜索資料是這方面的聲音比較多。
在我查資料的過程中，我去參考了一些知名的開源項目。最後總結下來，其實增加 Code Review 並不會佔用太多的時間（當然也有需要投入較多時間的情況），另外大部分的 Code Review 最終淪爲了一種形式，這主要還是因爲姿勢不對的原因，短期看不到收益，很難堅持。
利用 Gitlab 做 Code Review
Code Review 作爲一項十分成熟的軟件構建環節，自然會配套十分成熟 的工具。通過工具可以大大的提升 review 效率和質量。我在網上搜索了下，這方面的工具還是非常多的，下面是我列舉的幾個比較常見的：
常見的一些 Review 工具
- Phabircator （Facebook)
- Gerrit (Google)
- Gitlab / Github
- ...
考慮到我們團隊本身在使用 gitlab，索性我們就選擇 gitlab 作爲工具先試試了。通過 Merge request 功能，我們可以方便的添加 Code Review 環節開發流程。在我們熟知的 Github 中則是 pull request。目前我們的 Code Review 基本流程大致如下：
CR 基本流程
這也是從參考社區後製定的一個流程，目前其中的自動化 CI 工具我們還沒打通。爲了更順利和默契的進行這個環節，我們需要制定一個基礎的規範：
MR 注意項
保持獨立的 feature, bugfix、refactor 作爲分支進行 MR
提交的 commit 需要是有意義的描述，並帶上響應的 issue ID
複雜的 MR 內容，必要情況需添加 description 內容
MR 緊急，可以線下通知 Reviewers
Reviewer 相關
指定模塊最近參與修改的單個或多個同學作爲 Reviewer
指定參與相關模塊討論和 Desgin 過的人作爲 Reviewer
指定項目核心開發者作爲 Reviewer
如有必要， Reviewer 可分配給多個相關人
CheckList
- 錯誤、重複的 API 調用或者封裝
- 配置、接口類的設計問題（合理性、友好性）
- 架構類問題（業務/技術）
- 功能，邏輯的遺漏缺陷
- 無用的代碼或者註釋
- 可讀性差的變量、模塊等的命名
- 是否缺少應有的單元測試或者文檔
當然上面列舉的規則，隨着認知的提升可以不斷的完善更新。
配合工具更佳
爲了提升工作效率，我們可以在我們的 IDE 工具中安裝相關的各種插件，提升整個 Review 效率，由於我們大部分同學都在使用 VSCode，這裏我就列舉部分插件以作參考：
- ESLint 代碼靜態檢測, 解決基本的代碼風格不統一的問題，避免一些低級 bug。當然 ESLint 最好集成到 dev 構建環節中去
- GitLens 非常好的 git 可視化管理插件
- Gitlab MR 協助快速創建 MR 請求
總結
作爲一個需要長期維護的商業軟件，並在可預見的範圍內，項目仍然有很長的成長空間的情況來下，增加代碼審查環節是十分有必要的。無論是在傳統的瀑布模型（Waterfall Model）的迭代方法，還是當下最多的敏捷開發，代碼審查都是很重要的一環。在《代碼大全》討論質量提升的章節中有個統計，顯示代碼審查缺陷檢出率還是非常高的：
（圖片-2）來自代碼大全
我大概統計了下，截止 3 月底，數棧項目進行了約 350 + 次 merge 操作，有記錄的 comment 約 90 + 次，我計算了下，平均每次 MR 操作約會產生 0.25 次交流。這個數值應該不算高。後來大家總結下來，跟我們的預期有一些差別，例如 Bug 檢出率不高，不過很多基本 Bug 能一眼看出。最明顯的就是代碼質量的的提升，像重複、遺漏、可讀性等問題都很明顯的改善。
總而言之，大家總結下來結果對 Code Review 這個環節感覺還是很有意義的，當然還有很多不足點需要改善，例如提升 Review 質量，定期總結等等。