code review流程規(guī)范
張宇航：微醫(yī)前端技術(shù)部醫(yī)保支撐組，一個(gè)不文藝的處女座程序員。
前言
沒(méi)有無(wú)緣無(wú)故的愛(ài)，也沒(méi)有無(wú)緣無(wú)故的恨，當(dāng)然也沒(méi)有無(wú)緣無(wú)故的 code review
為什么要 CR
給大家講個(gè)故事，“大神 A”上班時(shí)突然惱羞成怒的罵道，這是誰(shuí)寫的代碼，沒(méi)有注釋啥也沒(méi)有，這么明顯的 bug。當(dāng)時(shí)整個(gè)小組都不敢說(shuō)話，慌的要死，生怕說(shuō)的就是自己。領(lǐng)導(dǎo)發(fā)話：“大神 A”查下提交記錄，誰(shuí)提交的誰(shuí)請(qǐng)吃飯。過(guò)了兩分鐘，“大神 A”：這，這是我自己一年前提交的。所以不想自己尷尬，趕緊 code review 吧
一、角色職能
author 即需求開(kāi)發(fā)者。要求：
注重注釋。對(duì)復(fù)雜業(yè)務(wù)寫明相應(yīng)注釋，commit 寫明具體提交背景，便于 reviewer 理解。 端正心態(tài)接受他人 review。對(duì) reviewer 給出的 comment，不要有抵觸的情緒，對(duì)你覺(jué)得不合理的建議，可以委婉地進(jìn)行拒絕，或者詳細(xì)說(shuō)明自己的看法以及原因。reviewer 持有的觀點(diǎn)并不一定是合理的，所以 review 也是一個(gè)相互學(xué)習(xí)的過(guò)程。 完成 comment 修改后及時(shí)反饋。commit 提交信息備注如"reivew: xxxx"，保證復(fù)檢效率。
reviewer 作為 cr 參與者，建議由項(xiàng)目責(zé)任人和項(xiàng)目參與者組成。要求：
說(shuō)明 comment 等級(jí)。reviewer 對(duì)相應(yīng)代碼段提出評(píng)價(jià)時(shí)，需要指明對(duì)應(yīng)等級(jí)，如 fix: xxxxxxx 此處需強(qiáng)制修改，提供修改建議 advise: xxxxxxx 此處主觀上建議修改，不強(qiáng)制，可提供修改建議 question: xxxxxx 此處存在疑慮，需要 author 作出解釋 友好 comment。評(píng)價(jià)注意措辭，可以說(shuō)“我們可以如何去調(diào)整修改，可能會(huì)更合適。。。”，對(duì)于比較好的代碼，也應(yīng)該給與足夠的贊美。 享受 review。避免以挑毛病的心態(tài) review，好的 reviewer 并不是以提的問(wèn)題多來(lái)衡量的。跳出自己的編碼風(fēng)格，主動(dòng)理解 author 的思路，也是一個(gè)很好的學(xué)習(xí)過(guò)程。
二、CR 流程
1、self-review
commit 之前要求 diff 一下，查看文件變更情況，可接著 gitk 完成。當(dāng)然如果項(xiàng)目使用 pre-commit 關(guān)聯(lián) lint 校驗(yàn)，也能發(fā)現(xiàn)例如 debugger、console.log 之類語(yǔ)句。但是仍然提倡大家每次提交之前檢查一下提交文件。 多人協(xié)作下的 commit。多人合作下的分支在合并請(qǐng)求時(shí)，需要關(guān)注是否帶入沒(méi)必要的 commit。 commit message。建議接入 husky、commitlint/cli 以及 commitlint/config-conventional 校驗(yàn) commit message。commitlint/config-conventional 所提供的類型如 feat: 新特性 fix: 修改 bug chore: 優(yōu)化，如項(xiàng)目結(jié)構(gòu)，依賴安裝更新等 docs: 文檔變更 style: 樣式相關(guān)修改 refactor：項(xiàng)目重構(gòu)
此目的為了進(jìn)一步增加 commit message 信息量，幫助 reviewer 以及自己更有效的了解 commit 內(nèi)容。
2、CR
提測(cè)時(shí)發(fā)起 cr，需求任務(wù)關(guān)聯(lián) reviewer。提供合并請(qǐng)求，借助 gitlab/sourcetree/vscode gitlens 等工具。reviewer 結(jié)束后給與反饋 針對(duì) reviewer 提出的建議修改之后，commit message 注明類似'review fix'相關(guān)信息，便于 reviewer 復(fù)檢。 緊急需求，特事特辦，跳過(guò) cr 環(huán)節(jié)，事后 review。
三、CR 標(biāo)準(zhǔn)
不糾結(jié)編碼風(fēng)格。編碼風(fēng)格交給 eslint/tslint/stylelint 代碼性能。大數(shù)據(jù)處理、重復(fù)渲染等 代碼注釋。字段注釋、文檔注釋等 代碼可讀性。過(guò)多嵌套、低效冗余代碼、功能獨(dú)立、可讀性變量方法命名等 代碼可擴(kuò)展性。功能方法設(shè)計(jì)是否合理、模塊拆分等 控制 review 時(shí)間成本。reviewer 盡量由項(xiàng)目責(zé)任人組成，關(guān)注代碼邏輯，無(wú)需逐字逐句理解。
四、最后
總的來(lái)說(shuō)，cr 并不是一個(gè)找 bug 挑毛病的過(guò)程，更不會(huì)降低整體開(kāi)發(fā)效率。其目的是為了保證項(xiàng)目的規(guī)范性，使得其他開(kāi)發(fā)人員在項(xiàng)目擴(kuò)展和維護(hù)時(shí)節(jié)省更多的時(shí)間和精力。當(dāng)然 cr 環(huán)節(jié)需要團(tuán)隊(duì)每一個(gè)成員去推動(dòng)，只有每一個(gè)人都認(rèn)可且參與進(jìn)來(lái)，才能發(fā)揮 cr 的最大價(jià)值。
最后安利一波本人開(kāi)發(fā) vscode 小插件搭配 gitlab 分支 review，主要流程是點(diǎn)擊按鈕發(fā)起合并請(qǐng)求，自動(dòng)生成 mr 鏈接，并發(fā)送至企業(yè)微信通知相關(guān)責(zé)任人開(kāi)始 review。