時間過得很快堕扶，轉(zhuǎn)眼間 Code Review 機制在丁香醫(yī)生前端團隊已經(jīng)運作一年多了。今年4月初時恼琼，將團隊在 Code Review 方面的一些經(jīng)驗在丁香園前端團隊進行了分享史隆，各個業(yè)務(wù)線的前端同學(xué)們逐步開始嘗試 Code Review 機制爆捞，目前也有了一定的收獲。是時候?qū)⑦@些實踐經(jīng)驗落實到文字上卡骂，來和更多的朋友們進行交流了壹士。

起因

世上沒有無緣無故的愛，也沒有無緣無故的恨偿警。同樣躏救，也沒有無緣無故的 Code Review。最開始時螟蒸，丁香醫(yī)生前端有2個人盒使，基本上是1人在做丁香醫(yī)生 SPA 項目，1人做丁香醫(yī)生管理后臺項目七嫌。

將時間點放到17年初少办，團隊從2個人變?yōu)榱?個人，此時主要有三個前端項目（丁香醫(yī)生 SPA诵原、丁香醫(yī)生管理后臺以及丁香醫(yī)生 Hybrid App）在迭代英妓，其中主要是 SPA 項目會涉及到三個人的交叉維護。這個階段便會開始暴露出一些小問題绍赛。比如：

• 編碼風格不一致
• 有些他人寫的業(yè)務(wù)邏輯蔓纠，在交叉維護時，需要花更多的時間上手
• 一些低級的 bug 在代碼部署到測試環(huán)境才被發(fā)現(xiàn)

為了解決這些問題吗蚌，我們決定開始嘗試 Code Review腿倚。項目的代碼是托管在公司內(nèi)網(wǎng)的 Gitlab 上的，于是我們會開始摸索著基于 GitLab 中項目的 Merge Request 進行他人代碼的 Code Review蚯妇。

17年 Q2 時敷燎，我們開始頻繁的迭代丁香醫(yī)生小程序，同時運營團隊也會開始提出一些運營類H5的需求箩言。團隊成員有4人了硬贯。隨著新鮮血液的加入，我們遇到了新的問題：

• 新人的加入提高了團隊代碼風格的差異性
• 在不是很了解現(xiàn)有項目的基礎(chǔ)上陨收，實現(xiàn)的新功能代碼會產(chǎn)生冗余
• 誰來為新成員的代碼質(zhì)量和成長負責饭豹？（注意：這是重要的一點）

此時我們依舊在做 Code Review，但實際上并沒有嚴格的去執(zhí)行，也沒有一個關(guān)于 Code Review 的標準供大家遵守墨状。

毫無疑問的一點：隨著丁香醫(yī)生業(yè)務(wù)的發(fā)展卫漫，這些問題是需要被解決的，否則長遠來看無論是對于團隊還是團隊成員肾砂，都是有較大傷害的列赎。

17 年 Q3 時，團隊已經(jīng)有 6 個人了镐确。每加入一個新人包吝，上述問題的復(fù)雜度就會增加一些。為了解決這些問題源葫，團隊決定將 Code Review 作為一項基本制度诗越，嚴格去執(zhí)行。

如何去做 Code Review息堂？

前提

在開始嚴格的去做 Code Review 之前嚷狞，我們確定了三點基礎(chǔ)規(guī)范。

1. 基于項目版本控制荣堰，統(tǒng)一項目遵守的 Git 分支模型
2. 對于 JavaScript床未，使用統(tǒng)一的 Eslint 規(guī)則
3. 結(jié)合團隊成員現(xiàn)有風格，明確統(tǒng)一的代碼規(guī)范

工具

使用的工具就地取材振坚，依舊是 GitLab薇搁。整個 Code Review 流程在 GitLab 項目中有兩個點比較關(guān)鍵：Merge Request（簡稱：MR）、Discussion（簡稱：Diss）渡八。

在這兩點基礎(chǔ)上啃洋，我們確定了幾個角色：

• Owner（需求負責人，代碼改動提交者屎鳍，MR 發(fā)起者）
• Reviewers（MR 參與者宏娄，前端團隊的同事，可能不止一個人哥艇。負責 Review 代碼绝编。）
• Disser（某個 Reviewer僻澎。對某個 MR 發(fā)起 Discussion 的人貌踏。）

流程

1. 對 GitLab 上需要進行 Code Review 的項目進行設(shè)置（Settings - General - Merge request settings - Only allow merge requests to be merged if all discussions are resolved）。
2. Owner 在本地開發(fā)環(huán)境窟勃，某分支（以某功能分支 feat-example 為例）做好功能開發(fā)祖乳，充分自測后將代碼推送到 GitLab。
3. Owner 基于 feat-example 分支秉氧，發(fā)起目標分支為 develop 分支的 MR眷昆。MR 需要有盡可能詳細的描述。比如：需求文檔地址，做了哪些修改亚斋，某個功能的設(shè)計實現(xiàn)思路作媚，需要哪幾位 reviewer 對本次 MR 進行 Code Review 等。推薦使用 MR 模板帅刊。
4. Owner 成功發(fā)起 MR 后纸泡，通過團隊協(xié)作工作告知 Reviewers 有 MR 需要進行 Code Review，以及 MR 的緊急程度赖瞒。
5. Reviewers 基于 MR 進行進行 code review女揭。如果對 MR 有任何問題，在 GitLab 上針對具體代碼進行 comment（發(fā)起 Discussion）栏饮，review 完成后通知 Owner 結(jié)果（本次 MR 通過 / 本次 MR 有 n 個 Diss）吧兔。如果有 Diss，Owner 需要對每一個 Diss 進行回復(fù)袍嬉，直至所有 Diss 的狀態(tài)變更為 Resolved境蔼。
6. Owner 對 MR 進行 merge 操作，并在測試環(huán)境發(fā)布代碼伺通，通知相關(guān) QA 同學(xué)測試欧穴，QA 測試通過后由 QA 通知產(chǎn)品和設(shè)計師進行驗收。（此處有一個細節(jié)：Owner 如果確定可以進行 merge 操作泵殴？我們想到有兩個方案：1. 以 Reviewers 通知 Owner 為準 2. 以 Reviewers 給 MR 點贊為準涮帘，因為 GitLab 上是可以對 MR 進行點贊操作的。目前團隊采用的是第2種方式笑诅。）
7. 如果測試或者驗收環(huán)節(jié)發(fā)現(xiàn)問題调缨，Owner 需要對代碼進行修改，然后發(fā)起新一輪的 MR吆你，直至測試環(huán)境代碼通過驗收弦叶。
8. 和 QA 同學(xué)確認代碼可以發(fā)布至生產(chǎn)環(huán)境，并進行代碼發(fā)布妇多，通知 case 相關(guān)同學(xué)某功能已上線伤哺。

原則

在執(zhí)行 Code Review 過程中，我們有一些原則需要遵守：

• Owner 發(fā)起 MR 之前的代碼需要進行充分自測
• 代碼版本控制 commit 的粒度不要太大
• 不阻塞他人的工作者祖，盡快響應(yīng)他人的 Code Review 請求（這一點比較考驗團隊成員的合作精神立莉、團隊意識。同時也要求開發(fā)者要合理安排自己的時間七问，要有能力隨時放下手中的工作蜓耻，隨時繼續(xù)手中的工作）
• 如果某個 MR 緊急，可以告知 Reviewers
• 除有必要械巡，否則 Owner 不要在提測驗收階段刪除分支（例如勾選“remove source branch when merge request is accepted.”）刹淌，應(yīng)等待分支合入master分支后移除饶氏，避免預(yù)發(fā)/測試分支重建時被遺漏。
• 定期回顧和總結(jié) Code Review 執(zhí)行情況（比如在團隊周會時進行）

邊界

清楚了 Code Review 流程之后有勾，其實還有一些邊界情況需要考慮疹启。我會將團隊目前采用的處理策略寫出來供參考。

1. 周末出現(xiàn)線上緊急 bug 要遵循 Code Review 流程嗎蔼卡？可以不進行 Code Review皮仁，以快速修復(fù) bug 為主。
2. 某個需求（項目）留給開發(fā)時間非常緊張時怎么辦菲宴？可以不進行 Code Review贷祈，優(yōu)先保證按時需求（項目）上線。
3. 團隊內(nèi)部項目喝峦、組內(nèi)同學(xué)個人發(fā)起的興趣項目是否需要進行 code review势誊？決定權(quán)在項目 Owner。
4. MR 遇到代碼沖突怎么辦谣蠢？建議在 code review 之后粟耻，由 Owner 將代碼拉取到本地進行 merge 并解決沖突，然后將最新代碼推送到 GitLab（此時 GitLab 上 MR 會自動 merge 掉）眉踱。

收獲

坦言挤忙，在一個從未進行過 Code Review 的團隊想把這個機制運作起來，并不是一件容易的事情谈喳。尤其是在決定開始進行 Code Review 后的起步階段册烈。但是如果能認準方向，團隊的成員齊心協(xié)力朝著既定的方向去走婿禽，最終會獲得如下的收獲的：

• 團隊成員代碼風格統(tǒng)一
• 減小了項目交叉維護的阻力
• 使新成員更快速融入團隊
• 避免了低級 bug 在測試環(huán)境出現(xiàn)
• 良好的技術(shù)交流氛圍

待完善

上面描述的這個機制并不是完美的赏僧。目前我可以想到的可以優(yōu)化的點如下：

• 優(yōu)化編碼規(guī)范（技術(shù)本身在發(fā)展，團隊成員的水平在提高扭倾，隨之之前定下來的編碼規(guī)范也會適當?shù)倪M行優(yōu)化）
• Check List（這一點實際上目前團隊已經(jīng)開始做了淀零。當業(yè)務(wù)具有一定復(fù)雜度后，某些業(yè)務(wù)邏輯的迭代難免會牽扯較多已有業(yè)務(wù)膛壹，此時如果有一份 Check List驾中，會幫助 Owner 及 Reviewers 更好的進行 Code Review）
• 激勵機制
• 代碼測試用例（主要是指業(yè)務(wù)代碼增加測試用例。目前團隊也開始進行了一些嘗試模聋。）
• 自動化

寫在最后

將團隊在使用的 Code Review 機制以文字的形式沉淀下來肩民，主要是想分享給更多的人。如果這些文字對某些人撬槽、某些團隊有幫助此改，那對于我來說是一件令人欣慰的事情。如果能接收到關(guān)于優(yōu)化現(xiàn)有機制的指點侄柔，也會是一件令人開心和感激的事情共啃。

此外，還想表達的一點是：丁香醫(yī)生前端團隊是一個非常在意每一個團隊成員成長的團隊暂题。

我猜移剪，你可能猜到接下來我要說什么了。

是的薪者，隨著丁香醫(yī)生業(yè)務(wù)的發(fā)展纵苛，我們需要優(yōu)秀的前端同學(xué)加入我們，一起茁壯肆意成長言津。更多關(guān)于團隊的介紹攻人，可以參考請問丁香醫(yī)生前端團隊怎么樣？

作者：丁香園F2E
鏈接：https://juejin.im/post/5b97d684e51d450ea363092f
來源：掘金
著作權(quán)歸作者所有悬槽。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)怀吻，非商業(yè)轉(zhuǎn)載請注明出處。