有讚美業前端： 持續標準化 Code Review

關鍵字：代碼質量 團隊建設 流程優化

1、背景

1. 技術棧

美業技術團隊前端對外的業務項目的主要編程技術棧是：

2. 團隊架構

在構建項目的前期，前端對業務項目按端來劃分人員，各端各司其職，各自沉澱。

中期隨着產品的基本成型，前端團隊人員按照業務領域劃分紅了多個子業務組前端，各組負責4端中對應模塊的業務。

因而，咱們美業團隊20個前端幾乎每一個人都要維護4個不一樣的編碼上下文的項目，好處是技術多樣性豐富，可是瓶頸也一樣存在，一我的須要擁有多端的開發能力，在編碼規範和代碼風格檢查儘量統一的狀況下，由於上述技術體系的差別，咱們仍是不得不須要熟悉四端的技術架構、開發流程、數據流處理、資產市場、最佳實踐。

這是頗有挑戰的，業務小組之間成立了一個小型的前端技術委員會，來應對這種變化：

• 總結原先的項目技術規範，統一宣講、培訓、文檔化
• 打造統一標準化的研發流程
• 而且持續汲取新的實踐並迭代

3. 代碼質量問題

隨即，咱們在代碼質量上迎來了一些問題：

• 項目Bug較多，一樣的坑不一樣的人會踩
• 迭代後的代碼難維護，包括代碼可讀性差、複用度低等
• 模塊的總體設計也欠缺，擴展能力難以支撐業務發展。

對代碼質量的把控方面，現狀流程是：咱們半年要對幾端的項目代碼進行一次總體的code review。

可是和垃圾回收同樣，總體的標記清除佔用人員的時間較長，會影響屆時涉及人員的業務開發進度。

因而咱們想探索一種適合咱們團隊和業務發展，小步快跑模式的code Review，儘量早的從一開始就參與進來，更高頻率，加強審查和設計把控，減小後面返工和帶來Bug所影響的總體效率。

2、定義需求

有了這樣的背景和改進訴求，我發現咱們得從新定義一下咱們作這件事情的目的和價值。

通過思考和討論，咱們作 Code Review 的核心目的只有兩個：

1. 從源頭把控代碼質量和效率

• 統一代碼評判標準和認知
• 發現邊界問題
• 提出改進建議

2. 共享和迭代集體代碼智慧

• 交流計思路和編碼實踐
• 沉澱最佳實踐
• 迭代統一規範

同時要作上述理想中的 Code Review，咱們可能不得不面臨這些實踐過程當中會遇到的問題：

基於這些訴求和待解決問題，咱們須要對總體的標準和每一次 Code Review 的關鍵控制點進行細化和量化，因而有了咱們初版 Code Review 的 SOP（標準做業流程）。

3、V1.0 標準化

1. 創建規範

1.1 宣講

宣講各端統一代碼規範和最佳實踐、編碼原則。Code Review的基礎是有基本的代碼規範和原則，同時要同步給你們。

1.2 review 小組

成立專門的 code review 小組，小組成員是各端經驗豐富的人員，這樣才能比較好的保障初期 Review 有比較好的效果，可讓 Code 人員有更大所獲，先富帶後富，通過屢次 Code Review 對齊標準以後，更多 Code 優秀的同窗也能夠加入進來，討論對規範和原則的實踐。

1.3 設定可迭代的代碼質量評價維度和標準：

每項1~5分，基準分爲3分，得分在此基礎上根據評分點浮動，總評分爲各項得分的平均分。

① 基本面：對團隊既定規範的遵循和代碼開發的改動量是咱們作評分的第一個基礎。

• 難度大、工做量大，可酌情加分
• 是否符合基本規範

② 架構設計：是否有總體設計，設計是否合理，設計是否遵循了設計，這是第二個維度

• 若是有設計文檔，是否按照設計文檔思路來寫代碼，是可酌情加分
• review的人是否發現了更好的解決方案
• 代碼是否提供了很好的解決思路

③ 代碼：代碼細節上是否儘量保持簡單和易讀，同時鼓勵細節優化是咱們的第三個維度

• 是否明顯重複代碼
• 是否合理抽取枚舉值，禁止使用「魔法值」
• 是否合理使用已有的組件和方法
• 對已有的、不合理的代碼進行重構和優化
• 職責（組件、方法）、概念是否清晰

④ 健壯性：錯誤處理、業務邏輯的邊界和基本的安全性是咱們的第四個維度

• 邊界和異常是否考慮完備
• 在review階段是否發現明顯bug
• 是否考慮安全性（xss）

⑤ 效率：是否貢獻了總體，爲物料庫和工具庫添磚加瓦，與總體沉澱造成閉環，是咱們第五個維度的初衷

• 是否抽取共用常量到beauty-const庫，加分
• 是否抽取沉澱基礎組件和通用業務組件到組件庫，加分

1.4 申請格式

Code 人在企業微信羣發起 Review 申請，統一參考格式，內容包括：

mr地址、產品文檔、UI稿、技術設計、效率平臺、接口文檔

原則是能爲 Review 方儘量提供足夠的信息來判斷 Code 的好壞，去更好發現深層次問題。
固然文檔也說不到所有的上下文，因此咱們須要分配 Review 人員時候要考慮技術棧和業務相關熟悉度，必要時候 Code 人員要向 Review 人員口述需求、代碼思路和重點。

1.5 review 要求

• code review 必須在提測前進行，確保上線前可以完成 Review。
• review 人根據 code review 評分標準 打出各項評分，計算出本次 code review 總評分
• 有須要可在備註中說明緣由，代碼相關的備註能夠直接在 gitlab 進行
• code 解決反饋的問題
• 要求提測郵件中體現 code review 狀況（評分、遺留問題）
• mr 統一由 feature 分支合到 release 分支
• review 記錄，按期同步分享

1.6 review 重點

• 建議check代碼改動範圍，重點關注核心代碼改動的影響
• review能夠針對重點代碼進行
• 每項checklist，若是有不符合checklist內容的，請在後面【評分解釋】中具體指出
• 「討論沉澱」內容可包括但不限於：技術設計狀況、review過程當中發現的亮點與不足、值得探討的東西、發現的bug
• 週會按期同步 review 狀況，分享優秀代碼

2. 單次流程

3. 產出示例

• 經過統一提交文檔和口述，Code 方養成了技術設計和理清重點和評估影響範圍的習慣。
• 經過討論和反饋 Code Review 雙方都從討論中獲取到了編碼智慧的碰撞和交流，總體的代碼水平總和獲得了提高。
• 經過 Review，代碼的整體設計和細節獲得了更好的保障。
• 經過沉澱最佳實踐和改進建議，團隊規範和 Code Review 造成了內循環。

4、V2.0 平臺化

1.0版本在持續的細節迭代，作到了比較滿意的標準化做業，可是有幾個比較大的缺陷：

1.操做欠缺自動化

• 流程的不少環節明顯能夠自動化，節省重複的工做量
• 對流程的把控依賴人，容易執行不到位

2.信息欠缺數字化

• 對 code review 的評分統計須要人工，工做量大
• code review 的總覽和數據分析能夠支撐更好的判斷團隊問題和決策提高總體代碼質量的策略

3.流程欠缺可視化

• 全部流程應該是能夠大盤總覽，單個詳情全面的
• 每一個code review事務的狀態是可見的

因此咱們有了把 Code Review 整套流程作成已有的內部前端工具平臺中一個模塊的想法，以期達到可視化、自動化、數字化的目的。

投入產出比是咱們須要考慮的，咱們很篤定。由於雖然這件事情沒有直接的業務價值，可是有很是好的質量把控和能力量化的價值，而且有標杆式的團隊建設價值，人員成長了，更好地爲業務服務。

1. 需求分析

在完成上述基本需求以後，咱們同時在收集反饋新增了

1. code 人可指定 review 人員
2. 支持項目多端配置
3. 首頁 review 得分榜排名展現
4. 最佳實踐統一導出
5. 打通關聯項目平臺串聯項目

2. 技術設計

結合數據庫表設計以後，咱們就分工開整了。

3. 產品效果圖

• Code Review 平臺化以後，打通了相關平臺，自動化了人工的重複操做，聚焦在 Code 和 思考上面，無需關心流程狀態。
• 團隊對 Code 狀況有了更好的全局性把控，可以進一步根據狀況和數據分析對代碼質量提高作決策。

5、可持續保障機制

前人種樹，後人除了乘涼以外得繼續澆灌。流程和機制是死的，咱們得用一些更加有溫度的一些策略讓它持續能夠迭代和發展繼承下去。

1. 半年度頒獎：半年咱們會把半年你們的評分紅績統計出來，作一次激勵，樹立標杆，鼓勵你們繼續寫出更好的代碼，也繼續的配合 Code Review。
2. 專人 Owner：做爲一個技術項目來持續維護和收集反饋意見迭代，服務小夥伴，爲團隊建設助力。
3. 歸入考覈：做爲複雜的大型 SaaS 項目的開發者，代碼能力是咱們考覈小夥伴專業能力的重要維度。

附帶一些半年頒獎的圖：

本文篇幅有限，實踐過程當中不少的細節問題和處理沒有闡述，好比 code、review 雙方的協做處理等。歡迎進一步討論。

微信：zz94530

---

目前有贊深圳研發團隊大量招聘高級前端，歡迎諮詢和投簡歷~