前言沒有無緣無故的愛，也沒有無緣無故的恨，當然也沒有無緣無故的 code review
為什麼要 CR給大家講個故事，「大神 A」上班時突然惱羞成怒的罵道，這是誰寫的代碼，沒有注釋啥也沒有，這麼明顯的 bug。當時整個小組都不敢說話，慌的要死，生怕說的就是自己。領導發話：「大神 A」查下提交記錄，誰提交的誰請吃飯。過了兩分鐘，「大神 A」：這，這是我自己一年前提交的。所以不想自己尷尬，趕緊 code review 吧
一、角色職能
author 即需求開發者。要求：
注重注釋。對複雜業務寫明相應注釋，commit 寫明具體提交背景，便於 reviewer 理解。端正心態接受他人 review。對 reviewer 給出的 comment，不要有牴觸的情緒，對你覺得不合理的建議，可以委婉地進行拒絕，或者詳細說明自己的看法以及原因。reviewer 持有的觀點並不一定是合理的，所以 review 也是一個相互學習的過程。完成 comment 修改後及時反饋。commit 提交信息備註如"reivew: xxxx"，保證復檢效率。reviewer 作為 cr 參與者，建議由項目責任人和項目參與者組成。要求：
說明 comment 等級。reviewer 對相應代碼段提出評價時，需要指明對應等級，如fix: xxxxxxx 此處需強制修改，提供修改建議advise: xxxxxxx 此處主觀上建議修改，不強制，可提供修改建議question: xxxxxx 此處存在疑慮，需要 author 作出解釋友好 comment。評價注意措辭，可以說「我們可以如何去調整修改，可能會更合適。。。」，對於比較好的代碼，也應該給與足夠的讚美。享受 review。避免以挑毛病的心態 review，好的 reviewer 並不是以提的問題多來衡量的。跳出自己的編碼風格，主動理解 author 的思路，也是一個很好的學習過程。二、CR 流程1、self-reviewcommit 之前要求 diff 一下，查看文件變更情況，可接着 gitk 完成。當然如果項目使用 pre-commit 關聯 lint 校驗，也能發現例如 debugger、console.log 之類語句。但是仍然提倡大家每次提交之前檢查一下提交文件。多人協作下的 commit。多人合作下的分支在合併請求時，需要關注是否帶入沒必要的 commit。commit message。建議接入 husky、commitlint/cli 以及 commitlint/config-conventional 校驗 commit message。commitlint/config-conventional 所提供的類型如此目的為了進一步增加 commit message 信息量，幫助 reviewer 以及自己更有效的了解 commit 內容。
2、CR提測時發起 cr，需求任務關聯 reviewer。提供合併請求，藉助 gitlab/sourcetree/vscode gitlens 等工具。reviewer 結束後給與反饋針對 reviewer 提出的建議修改之後，commit message 註明類似'review fix'相關信息，便於 reviewer 復檢。緊急需求，特事特辦，跳過 cr 環節，事後 review。三、CR 標準不糾結編碼風格。編碼風格交給 eslint/tslint/stylelint代碼可讀性。過多嵌套、低效冗餘代碼、功能獨立、可讀性變量方法命名等控制 review 時間成本。reviewer 儘量由項目責任人組成，關注代碼邏輯，無需逐字逐句理解。四、最後總的來說，cr 並不是一個找 bug 挑毛病的過程，更不會降低整體開發效率。其目的是為了保證項目的規範性，使得其他開發人員在項目擴展和維護時節省更多的時間和精力。當然 cr 環節需要團隊每一個成員去推動，只有每一個人都認可且參與進來，才能發揮 cr 的最大價值。
最後安利一波本人開發 vscode 小插件搭配 gitlab 分支 review，主要流程是點擊按鈕發起合併請求，自動生成 mr 鏈接，並發送至企業微信通知相關責任人開始 review。
留言列表