有贊美業(yè)前端: 持續(xù)標(biāo)準(zhǔn)化 Code Review
作者:邊城到此莫若(有贊)
來(lái)源:https://segmentfault.com/a/1190000025141916
關(guān)鍵字:代碼質(zhì)量 團(tuán)隊(duì)建設(shè) 流程優(yōu)化
一、背景
1. 技術(shù)棧
美業(yè)技術(shù)團(tuán)隊(duì)前端對(duì)外的業(yè)務(wù)項(xiàng)目的主要編程技術(shù)棧是:

2. 團(tuán)隊(duì)架構(gòu)
在構(gòu)建項(xiàng)目的前期,前端對(duì)業(yè)務(wù)項(xiàng)目按端來(lái)劃分人員,各端各司其職,各自沉淀。
中期隨著產(chǎn)品的基本成型,前端團(tuán)隊(duì)人員按照業(yè)務(wù)領(lǐng)域劃分成了多個(gè)子業(yè)務(wù)組前端,各組負(fù)責(zé)4端中對(duì)應(yīng)模塊的業(yè)務(wù)。
于是,我們美業(yè)團(tuán)隊(duì)20個(gè)前端幾乎每個(gè)人都要維護(hù)4個(gè)不同的編碼上下文的項(xiàng)目,好處是技術(shù)多樣性豐富,但是瓶頸也同樣存在,一個(gè)人需要擁有多端的開(kāi)發(fā)能力,在編碼規(guī)范和代碼風(fēng)格檢查盡可能統(tǒng)一的情況下,因?yàn)樯鲜黾夹g(shù)體系的差異,我們還是不得不需要熟悉四端的技術(shù)架構(gòu)、開(kāi)發(fā)流程、數(shù)據(jù)流處理、資產(chǎn)市場(chǎng)、最佳實(shí)踐。
這是很有挑戰(zhàn)的,業(yè)務(wù)小組之間成立了一個(gè)小型的前端技術(shù)委員會(huì),來(lái)應(yīng)對(duì)這種變化:
總結(jié)原先的項(xiàng)目技術(shù)規(guī)范,統(tǒng)一宣講、培訓(xùn)、文檔化 打造統(tǒng)一標(biāo)準(zhǔn)化的研發(fā)流程 并且持續(xù)汲取新的實(shí)踐并迭代

3. 代碼質(zhì)量問(wèn)題
隨即,我們?cè)诖a質(zhì)量上迎來(lái)了一些問(wèn)題:
項(xiàng)目Bug較多,同樣的坑不同的人會(huì)踩 迭代后的代碼難維護(hù),包括代碼可讀性差、復(fù)用度低等 模塊的整體設(shè)計(jì)也欠缺,擴(kuò)展能力難以支撐業(yè)務(wù)發(fā)展。
對(duì)代碼質(zhì)量的把控方面,現(xiàn)狀流程是:我們半年要對(duì)幾端的項(xiàng)目代碼進(jìn)行一次整體的code review。
但是和垃圾回收一樣,整體的標(biāo)記清除占用人員的時(shí)間較長(zhǎng),會(huì)影響屆時(shí)涉及人員的業(yè)務(wù)開(kāi)發(fā)進(jìn)度。
于是我們想探索一種適合我們團(tuán)隊(duì)和業(yè)務(wù)發(fā)展,小步快跑模式的code Review,盡可能早的從一開(kāi)始就參與進(jìn)來(lái),更高頻率,增強(qiáng)審查和設(shè)計(jì)把控,減少后面返工和帶來(lái)Bug所影響的整體效率。
二、定義需求
有了這樣的背景和改進(jìn)訴求,我發(fā)現(xiàn)我們得重新定義一下我們做這件事情的目的和價(jià)值。
經(jīng)過(guò)思考和討論,我們做 Code Review 的核心目的只有兩個(gè):
1. 從源頭把控代碼質(zhì)量和效率
統(tǒng)一代碼評(píng)判標(biāo)準(zhǔn)和認(rèn)知 發(fā)現(xiàn)邊界問(wèn)題 提出改進(jìn)建議
2. 共享和迭代集體代碼智慧
交流計(jì)思路和編碼實(shí)踐 沉淀最佳實(shí)踐 迭代統(tǒng)一規(guī)范
同時(shí)要做上述理想中的 Code Review,我們可能不得不面臨這些實(shí)踐過(guò)程中會(huì)遇到的問(wèn)題:

基于這些訴求和待解決問(wèn)題,我們需要對(duì)整體的標(biāo)準(zhǔn)和每一次 Code Review 的關(guān)鍵控制點(diǎn)進(jìn)行細(xì)化和量化,于是有了我們第一版 Code Review 的 SOP(標(biāo)準(zhǔn)作業(yè)流程)。
三、V1.0 標(biāo)準(zhǔn)化
1. 建立規(guī)范
1.1 宣講
宣講各端統(tǒng)一代碼規(guī)范和最佳實(shí)踐、編碼原則。Code Review的基礎(chǔ)是有基本的代碼規(guī)范和原則,同時(shí)要同步給大家。
1.2 review 小組
成立專(zhuān)門(mén)的 code review 小組,小組成員是各端經(jīng)驗(yàn)豐富的人員,這樣才能比較好的保障初期 Review 有比較好的效果,可以讓 Code 人員有更大所獲,先富帶后富,經(jīng)過(guò)多次 Code Review 對(duì)齊標(biāo)準(zhǔn)之后,更多 Code 優(yōu)秀的同學(xué)也可以加入進(jìn)來(lái),討論對(duì)規(guī)范和原則的實(shí)踐。
1.3 設(shè)定可迭代的代碼質(zhì)量評(píng)價(jià)維度和標(biāo)準(zhǔn):
每項(xiàng)1~5分,基準(zhǔn)分為3分,得分在此基礎(chǔ)上根據(jù)評(píng)分點(diǎn)浮動(dòng),總評(píng)分為各項(xiàng)得分的平均分。
① 基本面:對(duì)團(tuán)隊(duì)既定規(guī)范的遵循和代碼開(kāi)發(fā)的改動(dòng)量是我們做評(píng)分的第一個(gè)基礎(chǔ)。
難度大、工作量大,可酌情加分 是否符合基本規(guī)范
② 架構(gòu)設(shè)計(jì):是否有整體設(shè)計(jì),設(shè)計(jì)是否合理,設(shè)計(jì)是否遵循了設(shè)計(jì),這是第二個(gè)維度
如果有設(shè)計(jì)文檔,是否按照設(shè)計(jì)文檔思路來(lái)寫(xiě)代碼,是可酌情加分 review的人是否發(fā)現(xiàn)了更好的解決方案 代碼是否提供了很好的解決思路
③ 代碼:代碼細(xì)節(jié)上是否盡可能保持簡(jiǎn)單和易讀,同時(shí)鼓勵(lì)細(xì)節(jié)優(yōu)化是我們的第三個(gè)維度
是否明顯重復(fù)代碼 是否合理抽取枚舉值,禁止使用“魔法值” 是否合理使用已有的組件和方法 對(duì)已有的、不合理的代碼進(jìn)行重構(gòu)和優(yōu)化 職責(zé)(組件、方法)、概念是否清晰
④ 健壯性:錯(cuò)誤處理、業(yè)務(wù)邏輯的邊界和基本的安全性是我們的第四個(gè)維度
邊界和異常是否考慮完備 在review階段是否發(fā)現(xiàn)明顯bug 是否考慮安全性(xss)
⑤ 效率:是否貢獻(xiàn)了整體,為物料庫(kù)和工具庫(kù)添磚加瓦,與整體沉淀形成閉環(huán),是我們第五個(gè)維度的初衷
是否抽取共用常量到beauty-const庫(kù),加分 是否抽取沉淀基礎(chǔ)組件和通用業(yè)務(wù)組件到組件庫(kù),加分
1.4 申請(qǐng)格式
Code 人在企業(yè)微信群發(fā)起 Review 申請(qǐng),統(tǒng)一參考格式,內(nèi)容包括:
mr地址、產(chǎn)品文檔、UI稿、技術(shù)設(shè)計(jì)、效率平臺(tái)、接口文檔
原則是能為 Review 方盡可能提供足夠的信息來(lái)判斷 Code 的好壞,去更好發(fā)現(xiàn)深層次問(wèn)題。
當(dāng)然文檔也說(shuō)不到全部的上下文,所以我們需要分配 Review 人員時(shí)候要考慮技術(shù)棧和業(yè)務(wù)相關(guān)熟悉度,必要時(shí)候 Code 人員要向 Review 人員口述需求、代碼思路和重點(diǎn)。
1.5 review 要求
code review 必須在提測(cè)前進(jìn)行,確保上線前能夠完成 Review。 review 人根據(jù) code review 評(píng)分標(biāo)準(zhǔn) 打出各項(xiàng)評(píng)分,計(jì)算出本次 code review 總評(píng)分 有需要可在備注中說(shuō)明原因,代碼相關(guān)的備注可以直接在 gitlab 進(jìn)行 code 解決反饋的問(wèn)題 要求提測(cè)郵件中體現(xiàn) code review 情況(評(píng)分、遺留問(wèn)題) mr 統(tǒng)一由 feature 分支合到 release 分支 review 記錄,定期同步分享
1.6 review 重點(diǎn)
建議check代碼改動(dòng)范圍,重點(diǎn)關(guān)注核心代碼改動(dòng)的影響 review可以針對(duì)重點(diǎn)代碼進(jìn)行 每項(xiàng)checklist,如果有不符合checklist內(nèi)容的,請(qǐng)?jiān)诤竺妗驹u(píng)分解釋】中具體指出 「討論沉淀」內(nèi)容可包括但不限于:技術(shù)設(shè)計(jì)情況、review過(guò)程中發(fā)現(xiàn)的亮點(diǎn)與不足、值得探討的東西、發(fā)現(xiàn)的bug 周會(huì)定期同步 review 情況,分享優(yōu)秀代碼
2. 單次流程

3. 產(chǎn)出示例

通過(guò)統(tǒng)一提交文檔和口述,Code 方養(yǎng)成了技術(shù)設(shè)計(jì)和理清重點(diǎn)和評(píng)估影響范圍的習(xí)慣。 通過(guò)討論和反饋 Code Review 雙方都從討論中獲取到了編碼智慧的碰撞和交流,整體的代碼水平總和得到了提升。 通過(guò) Review,代碼的總體設(shè)計(jì)和細(xì)節(jié)得到了更好的保障。 通過(guò)沉淀最佳實(shí)踐和改進(jìn)建議,團(tuán)隊(duì)規(guī)范和 Code Review 形成了內(nèi)循環(huán)。
四、V2.0 平臺(tái)化
1.0版本在持續(xù)的細(xì)節(jié)迭代,做到了比較滿意的標(biāo)準(zhǔn)化作業(yè),但是有幾個(gè)比較大的缺陷:
1.操作欠缺自動(dòng)化
流程的很多環(huán)節(jié)明顯可以自動(dòng)化,節(jié)省重復(fù)的工作量 對(duì)流程的把控依賴(lài)人,容易執(zhí)行不到位
2.信息欠缺數(shù)字化
對(duì) code review 的評(píng)分統(tǒng)計(jì)需要人工,工作量大 code review 的總覽和數(shù)據(jù)分析可以支撐更好的判斷團(tuán)隊(duì)問(wèn)題和決策提升整體代碼質(zhì)量的策略
3.流程欠缺可視化
所有流程應(yīng)該是可以大盤(pán)總覽,單個(gè)詳情全面的 每個(gè)code review事務(wù)的狀態(tài)是可見(jiàn)的
所以我們有了把 Code Review 整套流程做成已有的內(nèi)部前端工具平臺(tái)中一個(gè)模塊的想法,以期達(dá)到可視化、自動(dòng)化、數(shù)字化的目的。
投入產(chǎn)出比是我們需要考慮的,我們很篤定。因?yàn)殡m然這件事情沒(méi)有直接的業(yè)務(wù)價(jià)值,但是有非常好的質(zhì)量把控和能力量化的價(jià)值,并且有標(biāo)桿式的團(tuán)隊(duì)建設(shè)價(jià)值,人員成長(zhǎng)了,更好地為業(yè)務(wù)服務(wù)。
1. 需求分析

在完成上述基本需求之后,我們同時(shí)在收集反饋新增了
code 人可指定 review 人員 支持項(xiàng)目多端配置 首頁(yè) review 得分榜排名展示 最佳實(shí)踐統(tǒng)一導(dǎo)出 打通關(guān)聯(lián)項(xiàng)目平臺(tái)串聯(lián)項(xiàng)目
2. 技術(shù)設(shè)計(jì)


結(jié)合數(shù)據(jù)庫(kù)表設(shè)計(jì)之后,我們就分工開(kāi)整了。
3. 產(chǎn)品效果圖



Code Review 平臺(tái)化之后,打通了相關(guān)平臺(tái),自動(dòng)化了人工的重復(fù)操作,聚焦在 Code 和 思考上面,無(wú)需關(guān)心流程狀態(tài)。 團(tuán)隊(duì)對(duì) Code 情況有了更好的全局性把控,能夠進(jìn)一步根據(jù)情況和數(shù)據(jù)分析對(duì)代碼質(zhì)量提升做決策。
五、可持續(xù)保障機(jī)制
前人種樹(shù),后人除了乘涼之外得繼續(xù)澆灌。流程和機(jī)制是死的,我們得用一些更加有溫度的一些策略讓它持續(xù)可以迭代和發(fā)展繼承下去。
半年度頒獎(jiǎng):半年我們會(huì)把半年大家的評(píng)分成績(jī)統(tǒng)計(jì)出來(lái),做一次激勵(lì),樹(shù)立標(biāo)桿,鼓勵(lì)大家繼續(xù)寫(xiě)出更好的代碼,也繼續(xù)的配合 Code Review。 專(zhuān)人 Owner:作為一個(gè)技術(shù)項(xiàng)目來(lái)持續(xù)維護(hù)和收集反饋意見(jiàn)迭代,服務(wù)小伙伴,為團(tuán)隊(duì)建設(shè)助力。 納入考核:作為復(fù)雜的大型 SaaS 項(xiàng)目的開(kāi)發(fā)者,代碼能力是我們考核小伙伴專(zhuān)業(yè)能力的重要維度。
附帶一些半年頒獎(jiǎng)的圖:





本文篇幅有限,實(shí)踐過(guò)程中很多的細(xì)節(jié)問(wèn)題和處理沒(méi)有闡述,比如 code、review 雙方的協(xié)作處理等。歡迎進(jìn)一步討論。
微信:zz94530
目前有贊深圳研發(fā)團(tuán)隊(duì)大量招聘高級(jí)前端,歡迎咨詢和投簡(jiǎn)歷~
??愛(ài)心三連擊 1.看到這里了就點(diǎn)個(gè)在看支持下吧,你的「點(diǎn)贊,在看」是我創(chuàng)作的動(dòng)力。
2.關(guān)注公眾號(hào)
程序員成長(zhǎng)指北,回復(fù)「1」加入Node進(jìn)階交流群!「在這里有好多 Node 開(kāi)發(fā)者,會(huì)討論 Node 知識(shí),互相學(xué)習(xí)」!3.也可添加微信【ikoala520】,一起成長(zhǎng)。
“在看轉(zhuǎn)發(fā)”是最大的支持
