作為一家創新驅動的科技公司，袋鼠雲每年研發投入達數千萬，公司80%員工都是技術人員，袋鼠雲産品家族包括企業級一站式資料中台PaaS數棧、互動式資料可視化大屏開發平台Easy[V]等産品也在迅速疊代。在進行産品研發的過程中，技術小哥哥們能文能武，不斷提升産品性能和體驗的同時，也把這些提升和優化過程記錄下來，現錄入“袋鼠雲研發手記”專欄中，以和業内童鞋們分享交流。
下為“袋鼠雲研發手記”專欄第四期，本期作者為袋鼠雲前端團隊。
關于袋鼠雲前端團隊
知乎專欄@DTUX
袋鼠雲UX團隊擁有十多名專家級别，經驗豐富的前端開發工程師，分别支撐公司大數棧産品線的不同子項目的開發需求，具體包括資料中台産品「數棧」與資料可視化産品Easy[V]兩大塊。
在長期的項目實踐與産品疊代過程中，團隊成員在 React 技術棧、資料可視化技術、前端工程化等細分領域上不斷深耕探索，積累了豐富的經驗與最佳實踐，并分享在知乎專欄@DTUX：https://zhuanlan.zhihu.com/c_109929958
前言
這是一個持續了近兩年多時間的項目，項目由最開始隻有我一個人，到後來陸陸續續一共有 8 個同學先後給項目貢獻過代碼。如今代碼量已經達到了近 13W+ 行代碼，算的上是個不小的前端項目了。
代碼統計
兩年多的時間裡，大家都是間接的接手或者被接手彼此的代碼。 由于早期同時參與的時候最多也就 2 個同學，Code Review 這種事情似乎就顯得多餘了。不過在大概過了一年多之後，項目業務複雜度和代碼量已經達到了一定規模，而此時已經有 5，6 個不同工作背景的同學參與過這個項目了。此時項目逐漸暴露出來一些工程問題擺在眼前：
- 已完成的功能子產品經常容易改出新問題
- 重複的 API, 子產品封裝
- 奇怪的架構使用方法
- 代碼品質參差不齊
- 悶頭開發，對彼此的工作（代碼）并不熟悉，缺少交流
Code Review 的阻礙 & 疑慮
由于之前了解到的 Code Review 的資訊都是比較負面的，是以在團隊準備開始加上這個環節時還是有很多疑慮的：
- 疊代節奏緊迫（時間擔憂）
- 需求變更頻繁
- 形式主義，增加工作量，沒有太大意義
通過在網上搜尋相關資訊，我發現大家遇到的問題和疑慮無外乎這麼幾點。很多團隊的項目時間都非常緊張，功能都做不完，感覺代碼審查太浪費時間了。還有很多的情況是做着做着就淪為了
形式主義
, 我搜尋資料是這方面的聲音比較多。
在我查資料的過程中，我去參考了一些知名的開源項目。最後總結下來，其實增加 Code Review 并不會占用太多的時間（當然也有需要投入較多時間的情況），另外大部分的 Code Review 最終淪為了一種形式，這主要還是因為姿勢不對的原因，短期看不到收益，很難堅持。
利用 Gitlab 做 Code Review
Code 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）來自代碼大全