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