有贊美業(yè)前端： 持續(xù)標(biāo)準(zhǔn)化 Code Review
作者：邊城到此莫若（有贊）
來源：https://segmentfault.com/a/1190000025141916
關(guān)鍵字：代碼質(zhì)量 團隊建設(shè) 流程優(yōu)化
一、背景
1. 技術(shù)棧
美業(yè)技術(shù)團隊前端對外的業(yè)務(wù)項目的主要編程技術(shù)棧是：
2. 團隊架構(gòu)
在構(gòu)建項目的前期，前端對業(yè)務(wù)項目按端來劃分人員，各端各司其職，各自沉淀。
中期隨著產(chǎn)品的基本成型，前端團隊人員按照業(yè)務(wù)領(lǐng)域劃分成了多個子業(yè)務(wù)組前端，各組負責(zé)4端中對應(yīng)模塊的業(yè)務(wù)。
于是，我們美業(yè)團隊20個前端幾乎每個人都要維護4個不同的編碼上下文的項目，好處是技術(shù)多樣性豐富，但是瓶頸也同樣存在，一個人需要擁有多端的開發(fā)能力，在編碼規(guī)范和代碼風(fēng)格檢查盡可能統(tǒng)一的情況下，因為上述技術(shù)體系的差異，我們還是不得不需要熟悉四端的技術(shù)架構(gòu)、開發(fā)流程、數(shù)據(jù)流處理、資產(chǎn)市場、最佳實踐。
這是很有挑戰(zhàn)的，業(yè)務(wù)小組之間成立了一個小型的前端技術(shù)委員會，來應(yīng)對這種變化：
總結(jié)原先的項目技術(shù)規(guī)范，統(tǒng)一宣講、培訓(xùn)、文檔化 打造統(tǒng)一標(biāo)準(zhǔn)化的研發(fā)流程 并且持續(xù)汲取新的實踐并迭代
3. 代碼質(zhì)量問題
隨即，我們在代碼質(zhì)量上迎來了一些問題：
項目Bug較多，同樣的坑不同的人會踩 迭代后的代碼難維護，包括代碼可讀性差、復(fù)用度低等 模塊的整體設(shè)計也欠缺，擴展能力難以支撐業(yè)務(wù)發(fā)展。
對代碼質(zhì)量的把控方面，現(xiàn)狀流程是：我們半年要對幾端的項目代碼進行一次整體的code review。
但是和垃圾回收一樣，整體的標(biāo)記清除占用人員的時間較長，會影響屆時涉及人員的業(yè)務(wù)開發(fā)進度。
于是我們想探索一種適合我們團隊和業(yè)務(wù)發(fā)展，小步快跑模式的code Review，盡可能早的從一開始就參與進來，更高頻率，增強審查和設(shè)計把控，減少后面返工和帶來Bug所影響的整體效率。
二、定義需求
有了這樣的背景和改進訴求，我發(fā)現(xiàn)我們得重新定義一下我們做這件事情的目的和價值。
經(jīng)過思考和討論，我們做 Code Review 的核心目的只有兩個：
1. 從源頭把控代碼質(zhì)量和效率
統(tǒng)一代碼評判標(biāo)準(zhǔn)和認知 發(fā)現(xiàn)邊界問題 提出改進建議
2. 共享和迭代集體代碼智慧
交流計思路和編碼實踐 沉淀最佳實踐 迭代統(tǒng)一規(guī)范
同時要做上述理想中的 Code Review，我們可能不得不面臨這些實踐過程中會遇到的問題：
基于這些訴求和待解決問題，我們需要對整體的標(biāo)準(zhǔn)和每一次 Code Review 的關(guān)鍵控制點進行細化和量化，于是有了我們第一版 Code Review 的 SOP（標(biāo)準(zhǔn)作業(yè)流程）。
三、V1.0 標(biāo)準(zhǔn)化
1. 建立規(guī)范
1.1 宣講
宣講各端統(tǒng)一代碼規(guī)范和最佳實踐、編碼原則。Code Review的基礎(chǔ)是有基本的代碼規(guī)范和原則，同時要同步給大家。
1.2 review 小組
成立專門的 code review 小組，小組成員是各端經(jīng)驗豐富的人員，這樣才能比較好的保障初期 Review 有比較好的效果，可以讓 Code 人員有更大所獲，先富帶后富，經(jīng)過多次 Code Review 對齊標(biāo)準(zhǔn)之后，更多 Code 優(yōu)秀的同學(xué)也可以加入進來，討論對規(guī)范和原則的實踐。
1.3 設(shè)定可迭代的代碼質(zhì)量評價維度和標(biāo)準(zhǔn)：
每項1~5分，基準(zhǔn)分為3分，得分在此基礎(chǔ)上根據(jù)評分點浮動，總評分為各項得分的平均分。
① 基本面：對團隊既定規(guī)范的遵循和代碼開發(fā)的改動量是我們做評分的第一個基礎(chǔ)。
難度大、工作量大，可酌情加分 是否符合基本規(guī)范
② 架構(gòu)設(shè)計：是否有整體設(shè)計，設(shè)計是否合理，設(shè)計是否遵循了設(shè)計，這是第二個維度
如果有設(shè)計文檔，是否按照設(shè)計文檔思路來寫代碼，是可酌情加分 review的人是否發(fā)現(xiàn)了更好的解決方案 代碼是否提供了很好的解決思路
③ 代碼：代碼細節(jié)上是否盡可能保持簡單和易讀，同時鼓勵細節(jié)優(yōu)化是我們的第三個維度
是否明顯重復(fù)代碼 是否合理抽取枚舉值，禁止使用“魔法值” 是否合理使用已有的組件和方法 對已有的、不合理的代碼進行重構(gòu)和優(yōu)化 職責(zé)（組件、方法）、概念是否清晰
④ 健壯性：錯誤處理、業(yè)務(wù)邏輯的邊界和基本的安全性是我們的第四個維度
邊界和異常是否考慮完備 在review階段是否發(fā)現(xiàn)明顯bug 是否考慮安全性（xss）
⑤ 效率：是否貢獻了整體，為物料庫和工具庫添磚加瓦，與整體沉淀形成閉環(huán)，是我們第五個維度的初衷
是否抽取共用常量到beauty-const庫，加分 是否抽取沉淀基礎(chǔ)組件和通用業(yè)務(wù)組件到組件庫，加分
1.4 申請格式
Code 人在企業(yè)微信群發(fā)起 Review 申請，統(tǒng)一參考格式，內(nèi)容包括：
mr地址、產(chǎn)品文檔、UI稿、技術(shù)設(shè)計、效率平臺、接口文檔
原則是能為 Review 方盡可能提供足夠的信息來判斷 Code 的好壞，去更好發(fā)現(xiàn)深層次問題。
當(dāng)然文檔也說不到全部的上下文，所以我們需要分配 Review 人員時候要考慮技術(shù)棧和業(yè)務(wù)相關(guān)熟悉度，必要時候 Code 人員要向 Review 人員口述需求、代碼思路和重點。
1.5 review 要求
code review 必須在提測前進行，確保上線前能夠完成 Review。 review 人根據(jù) code review 評分標(biāo)準(zhǔn) 打出各項評分，計算出本次 code review 總評分 有需要可在備注中說明原因，代碼相關(guān)的備注可以直接在 gitlab 進行 code 解決反饋的問題 要求提測郵件中體現(xiàn) code review 情況（評分、遺留問題） mr 統(tǒng)一由 feature 分支合到 release 分支 review 記錄，定期同步分享
1.6 review 重點
建議check代碼改動范圍，重點關(guān)注核心代碼改動的影響 review可以針對重點代碼進行 每項checklist，如果有不符合checklist內(nèi)容的，請在后面【評分解釋】中具體指出 「討論沉淀」內(nèi)容可包括但不限于：技術(shù)設(shè)計情況、review過程中發(fā)現(xiàn)的亮點與不足、值得探討的東西、發(fā)現(xiàn)的bug 周會定期同步 review 情況，分享優(yōu)秀代碼
2. 單次流程
3. 產(chǎn)出示例
通過統(tǒng)一提交文檔和口述，Code 方養(yǎng)成了技術(shù)設(shè)計和理清重點和評估影響范圍的習(xí)慣。 通過討論和反饋 Code Review 雙方都從討論中獲取到了編碼智慧的碰撞和交流，整體的代碼水平總和得到了提升。 通過 Review，代碼的總體設(shè)計和細節(jié)得到了更好的保障。 通過沉淀最佳實踐和改進建議，團隊規(guī)范和 Code Review 形成了內(nèi)循環(huán)。
四、V2.0 平臺化
1.0版本在持續(xù)的細節(jié)迭代，做到了比較滿意的標(biāo)準(zhǔn)化作業(yè)，但是有幾個比較大的缺陷：
1.操作欠缺自動化
流程的很多環(huán)節(jié)明顯可以自動化，節(jié)省重復(fù)的工作量 對流程的把控依賴人，容易執(zhí)行不到位
2.信息欠缺數(shù)字化
對 code review 的評分統(tǒng)計需要人工，工作量大 code review 的總覽和數(shù)據(jù)分析可以支撐更好的判斷團隊問題和決策提升整體代碼質(zhì)量的策略
3.流程欠缺可視化
所有流程應(yīng)該是可以大盤總覽，單個詳情全面的 每個code review事務(wù)的狀態(tài)是可見的
所以我們有了把 Code Review 整套流程做成已有的內(nèi)部前端工具平臺中一個模塊的想法，以期達到可視化、自動化、數(shù)字化的目的。
投入產(chǎn)出比是我們需要考慮的，我們很篤定。因為雖然這件事情沒有直接的業(yè)務(wù)價值，但是有非常好的質(zhì)量把控和能力量化的價值，并且有標(biāo)桿式的團隊建設(shè)價值，人員成長了，更好地為業(yè)務(wù)服務(wù)。
1. 需求分析
在完成上述基本需求之后，我們同時在收集反饋新增了
code 人可指定 review 人員 支持項目多端配置 首頁 review 得分榜排名展示 最佳實踐統(tǒng)一導(dǎo)出 打通關(guān)聯(lián)項目平臺串聯(lián)項目
2. 技術(shù)設(shè)計
結(jié)合數(shù)據(jù)庫表設(shè)計之后，我們就分工開整了。
3. 產(chǎn)品效果圖
Code Review 平臺化之后，打通了相關(guān)平臺，自動化了人工的重復(fù)操作，聚焦在 Code 和 思考上面，無需關(guān)心流程狀態(tài)。 團隊對 Code 情況有了更好的全局性把控，能夠進一步根據(jù)情況和數(shù)據(jù)分析對代碼質(zhì)量提升做決策。
五、可持續(xù)保障機制
前人種樹，后人除了乘涼之外得繼續(xù)澆灌。流程和機制是死的，我們得用一些更加有溫度的一些策略讓它持續(xù)可以迭代和發(fā)展繼承下去。
半年度頒獎：半年我們會把半年大家的評分成績統(tǒng)計出來，做一次激勵，樹立標(biāo)桿，鼓勵大家繼續(xù)寫出更好的代碼，也繼續(xù)的配合 Code Review。 專人 Owner：作為一個技術(shù)項目來持續(xù)維護和收集反饋意見迭代，服務(wù)小伙伴，為團隊建設(shè)助力。 納入考核：作為復(fù)雜的大型 SaaS 項目的開發(fā)者，代碼能力是我們考核小伙伴專業(yè)能力的重要維度。
附帶一些半年頒獎的圖：
本文篇幅有限，實踐過程中很多的細節(jié)問題和處理沒有闡述，比如 code、review 雙方的協(xié)作處理等。歡迎進一步討論。
微信：zz94530
目前有贊深圳研發(fā)團隊大量招聘高級前端，歡迎咨詢和投簡歷~
