Code Review 在丁香醫生前端團隊的實踐

時間過得很快，轉眼間 Code Review 機制在丁香醫生前端團隊已經運做一年多了。今年4月初時，將團隊在 Code Review 方面的一些經驗在丁香園前端團隊進行了分享，各個業務線的前端同窗們逐步開始嘗試 Code Review 機制，目前也有了必定的收穫。是時候將這些實踐經驗落實到文字上，來和更多的朋友們進行交流了。

原由

世上沒有平白無故的愛，也沒有平白無故的恨。一樣，也沒有平白無故的 Code Review。最開始時，丁香醫生前端有2我的，基本上是1人在作丁香醫生 SPA 項目，1人作丁香醫生管理後臺項目。

將時間點放到17年初，團隊從2我的變爲了3我的，此時主要有三個前端項目（丁香醫生 SPA、丁香醫生管理後臺以及丁香醫生 Hybrid App）在迭代，其中主要是 SPA 項目會涉及到三我的的交叉維護。這個階段便會開始暴露出一些小問題。好比：

• 編碼風格不一致
• 有些他人寫的業務邏輯，在交叉維護時，須要花更多的時間上手
• 一些低級的 bug 在代碼部署到測試環境才被發現

爲了解決這些問題，咱們決定開始嘗試 Code Review。項目的代碼是託管在公司內網的 Gitlab 上的，因而咱們會開始摸索着基於 GitLab 中項目的 Merge Request 進行他人代碼的 Code Review。

17年 Q2 時，咱們開始頻繁的迭代丁香醫生小程序，同時運營團隊也會開始提出一些運營類H5的需求。團隊成員有4人了。隨着新鮮血液的加入，咱們遇到了新的問題：

• 新人的加入提升了團隊代碼風格的差別性
• 在不是很瞭解現有項目的基礎上，實現的新功能代碼會產生冗餘
• 誰來爲新成員的代碼質量和成長負責？（注意：這是重要的一點）

此時咱們依舊在作 Code Review，但實際上並無嚴格的去執行，也沒有一個關於 Code Review 的標準供你們遵照。

毫無疑問的一點：隨着丁香醫生業務的發展，這些問題是須要被解決的，不然長遠來看不管是對於團隊仍是團隊成員，都是有較大傷害的。

17 年 Q3 時，團隊已經有 6 我的了。每加入一個新人，上述問題的複雜度就會增長一些。爲了解決這些問題，團隊決定將 Code Review 做爲一項基本制度，嚴格去執行。

如何去作 Code Review？

前提

在開始嚴格的去作 Code Review 以前，咱們肯定了三點基礎規範。

1. 基於項目版本控制，統一項目遵照的 Git 分支模型
2. 對於 JavaScript，使用統一的 Eslint 規則
3. 結合團隊成員現有風格，明確統一的代碼規範

工具

使用的工具就地取材，依舊是 GitLab。整個 Code Review 流程在 GitLab 項目中有兩個點比較關鍵：Merge Request（簡稱：MR）、Discussion（簡稱：Diss）。

在這兩點基礎上，咱們肯定了幾個角色：

• Owner（需求負責人，代碼改動提交者，MR 發起者）
• Reviewers（MR 參與者，前端團隊的同事，可能不止一我的。負責 Review 代碼。）
• Disser（某個 Reviewer。對某個 MR 發起 Discussion 的人。）

流程

0. 對 GitLab 上須要進行 Code Review 的項目進行設置（Settings - General - Merge request settings - Only allow merge requests to be merged if all discussions are resolved）。
1. Owner 在本地開發環境，某分支（以某功能分支 feat-example 爲例）作好功能開發，充分自測後將代碼推送到 GitLab。
2. Owner 基於 feat-example 分支，發起目標分支爲 develop 分支的 MR。MR 須要有儘量詳細的描述。好比：需求文檔地址，作了哪些修改，某個功能的設計實現思路，須要哪幾位 reviewer 對本次 MR 進行 Code Review 等。推薦使用 MR 模板。
3. Owner 成功發起 MR 後，經過團隊協做工做告知 Reviewers 有 MR 須要進行 Code Review，以及 MR 的緊急程度。
4. Reviewers 基於 MR 進行進行 code review。若是對 MR 有任何問題，在 GitLab 上針對具體代碼進行 comment（發起 Discussion），review 完成後通知 Owner 結果（本次 MR 經過 / 本次 MR 有 n 個 Diss）。若是有 Diss，Owner 須要對每個 Diss 進行回覆，直至全部 Diss 的狀態變動爲 Resolved。
5. Owner 對 MR 進行 merge 操做，並在測試環境發佈代碼，通知相關 QA 同窗測試，QA 測試經過後由 QA 通知產品和設計師進行驗收。（此處有一個細節：Owner 若是肯定能夠進行 merge 操做？咱們想到有兩個方案：1. 以 Reviewers 通知 Owner 爲準 2. 以 Reviewers 給 MR 點贊爲準，由於 GitLab 上是能夠對 MR 進行點贊操做的。目前團隊採用的是第2種方式。）
6. 若是測試或者驗收環節發現問題，Owner 須要對代碼進行修改，而後發起新一輪的 MR，直至測試環境代碼經過驗收。
7. 和 QA 同窗確認代碼能夠發佈至生產環境，並進行代碼發佈，通知 case 相關同窗某功能已上線。

原則

在執行 Code Review 過程當中，咱們有一些原則須要遵照：

• Owner 發起 MR 以前的代碼須要進行充分自測
• 代碼版本控制 commit 的粒度不要太大
• 不阻塞他人的工做，儘快響應他人的 Code Review 請求（這一點比較考驗團隊成員的合做精神、團隊意識。同時也要求開發者要合理安排本身的時間，要有能力隨時放下手中的工做，隨時繼續手中的工做）
• 若是某個 MR 緊急，能夠告知 Reviewers
• 除有必要，不然 Owner 不要在提測驗收階段刪除分支（例如勾選「remove source branch when merge request is accepted.」），應等待分支合入master分支後移除，避免預發/測試分支重建時被遺漏。
• 按期回顧和總結 Code Review 執行狀況（好比在團隊週會時進行）

邊界

清楚了 Code Review 流程以後，其實還有一些邊界狀況須要考慮。我會將團隊目前採用的處理策略寫出來供參考。

1. 週末出現線上緊急 bug 要遵循 Code Review 流程嗎？能夠不進行 Code Review，以快速修復 bug 爲主。
2. 某個需求（項目）留給開發時間很是緊張時怎麼辦？能夠不進行 Code Review，優先保證按時需求（項目）上線。
3. 團隊內部項目、組內同窗我的發起的興趣項目是否須要進行 code review？決定權在項目 Owner。
4. MR 遇到代碼衝突怎麼辦？建議在 code review 以後，由 Owner 將代碼拉取到本地進行 merge 並解決衝突，而後將最新代碼推送到 GitLab（此時 GitLab 上 MR 會自動 merge 掉）。

收穫

坦言，在一個從未進行過 Code Review 的團隊想把這個機制運做起來，並非一件容易的事情。尤爲是在決定開始進行 Code Review 後的起步階段。可是若是能認準方向，團隊的成員齊心合力朝着既定的方向去走，最終會得到以下的收穫的：

• 團隊成員代碼風格統一
• 減少了項目交叉維護的阻力
• 使新成員更快速融入團隊
• 避免了低級 bug 在測試環境出現
• 良好的技術交流氛圍

待完善

上面描述的這個機制並非完美的。目前我能夠想到的能夠優化的點以下：

• 優化編碼規範（技術自己在發展，團隊成員的水平在提升，隨之以前定下來的編碼規範也會適當的進行優化）
• Check List（這一點實際上目前團隊已經開始作了。當業務具備必定複雜度後，某些業務邏輯的迭代不免會牽扯較多已有業務，此時若是有一份 Check List，會幫助 Owner 及 Reviewers 更好的進行 Code Review）
• 激勵機制
• 代碼測試用例（主要是指業務代碼增長測試用例。目前團隊也開始進行了一些嘗試。）
• 自動化

寫在最後

將團隊在使用的 Code Review 機制以文字的形式沉澱下來，主要是想分享給更多的人。若是這些文字對某些人、某些團隊有幫助，那對於我來講是一件使人欣慰的事情。若是能接收到關於優化現有機制的指點，也會是一件使人開心和感激的事情。

此外，還想表達的一點是：丁香醫生前端團隊是一個很是在乎每個團隊成員成長的團隊。

我猜，你可能猜到接下來我要說什麼了。

是的，隨着丁香醫生業務的發展，咱們須要優秀的前端同窗加入咱們，一塊兒茁壯肆意成長。更多關於團隊的介紹，能夠參考請問丁香醫生前端團隊怎麼樣？

招聘 JD

高級/資深前端工程師

職位描述

• 負責丁香醫生旗下產品的前端開發工做（網站，Web App，Hybrid App，微信小程序，管理後臺，Node.js 中間層）；
• 依據產品的需求，優質高效的完成前端項目的開發和維護；
• 對產品的前端性能進行優化，確保產品具備優質的用戶體驗；
• 參與丁香園前端團隊的基礎平臺建設；

任職條件

• 3 年以上前端工做經驗；
• 熟練使用 HTML（HTML5）、CSS（CSS3）和 JavaScript（ES6/ES7）；
• 熟悉網絡協議（HTTP/SSL）；
• 熟練使用 Webpack 或者 rollupjs；
• 至少熟練使用一種 CSS 預處理器（如：Less、Sass、Stylus）；
• 至少熟練使用 Vue.js、React.js、AngularJS 三種框架中的一種；
• 對前端開發規範、工程化、組件化、測試有必定的認識和實踐；
• 理解並熟練使用面向對象編程思想，注重設計模式、模塊化開發在實際項目中的應用；
• 較強的責任心，良好的溝通能力和文檔編寫能力；

優先條件

• 在簡歷裏寫明 Github 帳號或我的博客地址；
• 獨立開發過或者參與過優質的開源項目；
• 有實際 Hybrid App 項目開發經驗；
• 有實際的微信小程序項目開發經驗；
• 有高負載場景下 Node.js 應用開發和運維經驗；
• 熟練使用 TypeScript；
• 熟悉使用一門非前端的編程語言（如：Java、PHP、Python、Go）；

前端實習生（全職）

職位描述

• 負責丁香醫生旗下產品的前端開發工做（網站，Web App，Hybrid App，微信小程序，管理後臺，Node.js 中間層）；
• 依據產品的需求，優質高效的完成前端項目的開發和維護；
• 對產品的前端性能進行優化，確保產品具備優質的用戶體驗；
• 參與丁香園前端團隊的基礎平臺建設；

任職條件

• 對編程技術有熱情，指望本身在技術上有快速成長；
• 畢業前可以全職實習至少 6 個月；
• 熟練使用 HTML（HTML5）、CSS（CSS3）和 JavaScript（ES6/ES7）；
• 熟悉網絡協議（HTTP/SSL）；
• 理解並熟練使用面向對象編程思想，注重設計模式、模塊化開發在實際項目中的應用；
• 較強的責任心，良好的溝通能力和文檔編寫能力；

優先條件

• 在簡歷裏寫明 Github 帳號或我的博客地址；
• 獨立開發過或者參與過優質的開源項目；
• 熟練使用 Vue.js、React.js、AngularJS 三種框架中的一種；
• 有實際 Hybrid App 項目開發經驗；
• 有高負載場景下 Node.js 應用開發和運維經驗；
• 熟練使用 TypeScript；
• 熟練使用一種 CSS 預處理器（如：Less、Sass、Stylus）；
• 熟悉使用一門非前端的編程語言（如：Java、PHP、Python、Go）；

既然已經看到這裏了，不如發一封郵件咱們聊一下吧：lizy@dxy.cn。

本文做者：丁香園前端工程師 @志遙