code review 流程探索

張宇航：微醫前端技術部醫保支撐組，一個不文藝的處女座程序員。前端

前言

沒有平白無故的愛，也沒有平白無故的恨，固然也沒有平白無故的 code reviewgit

爲何要 CR

給你們講個故事，「大神 A」上班時忽然惱羞成怒的罵道，這是誰寫的代碼，沒有註釋啥也沒有，這麼明顯的 bug。當時整個小組都不敢說話，慌的要死，生怕說的就是本身。領導發話：「大神 A」查下提交記錄，誰提交的誰請吃飯。過了兩分鐘，「大神 A」：這，這是我本身一年前提交的。因此不想本身尷尬，趕忙 code review 吧程序員

1、角色職能

author 即需求開發者。要求：web

注重註釋。對複雜業務寫明相應註釋，commit 寫名具體提交背景，便於 reviewer 理解。
端正心態接受他人 review。對 reviewer 給出的 comment，不要有抵觸的情緒，對你以爲不合理的建議，能夠委婉地進行拒絕，或者詳細說明本身的見解以及緣由。reviewer 持有的觀點並不必定是合理的，因此 review 也是一個相互學習的過程。
完成 comment 修改後及時反饋。commit 提交信息備註如"reivew: xxxx"，保證複檢效率。

reviewer 做爲 cr 參與者，建議由項目責任人和項目參與者組成。要求：markdown

說明 comment 等級。reviewer 對相應代碼段提出評價時，須要指明對應等級，如
- fix: xxxxxxx 此處需強制修改，提供修改建議
- advise: xxxxxxx 此處主觀上建議修改，不強制，可提供修改建議
- question: xxxxxx 此處存在疑慮，須要 author 做出解釋
友好 comment。評價注意措辭，能夠說「咱們能夠如何去調整修改，可能會更合適。。。」，對於比較好的代碼，也應該給與足夠的讚美。
享受 review。避免以挑毛病的心態 review，好的 reviewer 並非以提的問題多來衡量的。跳出本身的編碼風格，主動理解 author 的思路，也是一個很好的學習過程。

2、CR 流程

一、self-review

commit 以前要求 diff 一下，查看文件變動狀況，可接着 gitk 完成。固然若是項目使用 pre-commit 關聯 lint 校驗，也能發現例如 debugger、console.log 之類語句。可是仍然提倡你們每次提交以前檢查一下提交文件。
多人協做下的 commit。多人合做下的分支在合併請求時，須要關注是否帶入不必的 commit。
commit message。建議接入 husky、commitlint/cli 以及 commitlint/config-conventional 校驗 commit message。commitlint/config-conventional 所提供的類型如
- feat: 新特性
- fix: 修改 bug
- chore: 優化，如項目結構，依賴安裝更新等
- docs: 文檔變動
- style: 樣式相關修改
- refactor：項目重構

此目的爲了進一步增長 commit message 信息量，幫助 reviewer 以及本身更有效的瞭解 commit 內容。工具

二、CR

提測時發起 cr，需求任務關聯 reviewer。提供合併請求，藉助 gitlab/sourcetree/vscode gitlens 等工具。reviewer 結束後給與反饋
針對 reviewer 提出的建議修改以後，commit message 註明相似'review fix'相關信息，便於 reviewer 複檢。
緊急需求，特事特辦，跳過 cr 環節，過後 review。

3、CR 標準

不糾結編碼風格。編碼風格交給 eslint/tslint/stylelint
代碼性能。大數據處理、重複渲染等
代碼註釋。字段註釋、文檔註釋等
代碼可讀性。過多嵌套、低效冗餘代碼、功能獨立、可讀性變量方法命名等
代碼可擴展性。功能方法設計是否合理、模塊拆分等
控制 review 時間成本。reviewer 儘可能由項目責任人組成，關注代碼邏輯，無需逐字逐句理解。

4、最後

總的來講，cr 並非一個找 bug 挑毛病的過程，更不會下降總體開發效率。其目的是爲了保證項目的規範性，使得其餘開發人員在項目擴展和維護時節省更多的時間和精力。固然 cr 環節須要團隊每個成員去推進，只有每個人都承認且參與進來，才能發揮 cr 的最大價值。gitlab

最後安利一波本人開發vscode小插件搭配gitlab進行review。由於涉及內部代碼，暫時不能對外開放，這裏暫時提供思路，後續開放具體代碼。性能