注：本文僅關(guān)注 Code Review 的實(shí)行，不討論 “為什么要 Code Review” 或 “Code Review 是否有價(jià)值” 這類話題。
通過 Code Review 來保證項(xiàng)目代碼質(zhì)量、提高團(tuán)隊(duì)的技術(shù)水平，已經(jīng)是很多公司的常規(guī)操作，大多數(shù)人也已經(jīng)認(rèn)可了進(jìn)行 Code Review 的必要性。然而，現(xiàn)實(shí)是這樣的：
”伴隨著號(hào)召和口號(hào)，大家熱情高漲，一頓操作花式輸出，目指用洞察世界的雙眼來拯救這個(gè)腐朽的Repo，而待多巴胺褪去，熱情難以為繼，全都恢復(fù)成了沒有感情的 Coder，三天打魚兩天曬網(wǎng)，再到最后完全流于形式，直至熱情再一次被喚醒……“
陷入循環(huán)中，我們不禁要吶喊：
“為什么Code Review這么麻煩這么累”
1. 錯(cuò)的不是我，是這個(gè)PR
Code Review 會(huì)讓人覺得麻煩、代碼看起來很累，很多情況下確實(shí)是因?yàn)檫@個(gè) PR 并不易于 Review，本身存在一些問題：
??????PR 太大：動(dòng)輒幾千行代碼、幾十個(gè)文件修改，打開一看就怕了怕了，沒有做好心理建設(shè)、備好兩三個(gè)小時(shí)的空閑時(shí)間誰敢 Review，告辭告辭；
? ??? PR 要做事的太多：東邊兒全局修改了變量名，西邊兒重構(gòu)了公用方法，南邊兒調(diào)整了頁(yè)面樣式，北邊兒還順便修了一個(gè)陳年老 bug……嚯，好家伙，一個(gè)迭代的需求一個(gè) PR 就提上來了，也就 Author 勉強(qiáng)在當(dāng)天還能搞清楚哪段是哪段，Reviewer 一路看下來就得懷疑人生；
? ??? PR 沒有上下文：“為什么要?jiǎng)h除這段代碼？為什么要加這么多分支邏輯？這么多類似的方法真的是必須的嗎？這種場(chǎng)景沒有判斷，是遺漏了還是業(yè)務(wù)需求？”你是否有很多問號(hào)？？？總會(huì)有很多問題，在缺乏上下文時(shí)，是很難給出解答的，不寫任何 Description，想要讓 Reviewer 自己主動(dòng)去搞清楚業(yè)務(wù)背景實(shí)在是不厚道，所以也別怪沒人肯 Review 了；
? ??? PR 代碼質(zhì)量太差：不遵守既定規(guī)范、格式亂七八糟、命名天馬行空、邏輯晦澀難懂，整篇代碼毫無“可讀性”可言，對(duì)于這種 PR，Review 兩眼是情分，直接Request Change才是本分。
2. 即使我有錯(cuò)，也是有原因的
如果，PR 確實(shí)不存在問題，代碼整潔、邏輯清晰，Description 安排地明明白白，卻還是沒能得到回應(yīng)，那的確應(yīng)該是 Reviewer 的問題，不過為他們考慮考慮，可能也是有原因的：
? ????工作量過于飽和：再簡(jiǎn)潔明了的 PR，Review 起來還是需要時(shí)間的，忙得已經(jīng)沒有喝水的時(shí)間，哪還有工夫去做 Code Review；
? ????道不同不相為謀：你有你的原則，我有我的風(fēng)格，既然誰也說服不了誰，那就這樣吧；
? ????技術(shù)領(lǐng)域不同：“我說另請(qǐng)高明吧，我實(shí)在也不是謙虛，我一個(gè)后端開發(fā)怎么就點(diǎn)進(jìn)前端PR了呢？”；
? ????看不出問題：雖然說起來有點(diǎn)尷尬，但確實(shí)是一個(gè)很普遍的情況，沒有掌握方法、相關(guān)技術(shù)儲(chǔ)備不足、Review 角度不同等等，一篇 PR 讀下來，似乎覺得哪里不對(duì)，又似乎也有道理，Comment 憋不出來、Approve 又不放心，那就跳過跳過，等其他大牛出手吧。
那么，有這么多嚴(yán)峻的問題存在，你看，我們還有機(jī)會(huì)嗎？
問得好！還記得文章的標(biāo)題嗎：
“我們不用很麻煩很累就可以 Code Review”
1. 作為 Author
? ????PR 盡可能小
????????○?創(chuàng)建 Draft PR：便于獲得早期反饋，避免在代碼成型后出現(xiàn)大規(guī)模的修改返工
????????○?PR 只關(guān)注一件事：降低閱讀 PR 時(shí)的認(rèn)知成本、更易于確定合理的 Assignee、Rollback 的可行性更高、開發(fā)更具計(jì)劃性
????????○?嚴(yán)格執(zhí)行 Rebase：避免引入不必要的修改或造成 Review 的返工
? ????添加關(guān)鍵的上下文
????????○?不可缺少的 Description（必要時(shí)可嘗試使用Github PR template輔助規(guī)范化），可以主要關(guān)注以下幾點(diǎn)：
??????????????這段代碼改動(dòng)的目的是？（通常情況下提供需求 Ticket 標(biāo)題及鏈接即可）
??????????????能預(yù)料可能會(huì)提出的問題，請(qǐng)?zhí)崆罢f明（如存在多種近似解決方案，選擇當(dāng)前方案的原因）
??????????????（若存在）特定邏輯需要特定 Reviewer 關(guān)注，請(qǐng)?zhí)崆罢f明
??????????????（若存在）批量修改，請(qǐng)?zhí)崆罢f明
??????????????（若存在）UI 修改，請(qǐng)?zhí)峁┢聊唤貓D或可查看到實(shí)際效果的鏈接
????????○?易于理解的 Commit Message，嚴(yán)厲抵制 ”fix bug“ 這種偷懶 message
????????○?代碼中添加必要的注釋
? ????Assign給正確的人
????????○?Assign組內(nèi)成員
????????○?期望能給出反饋的人:
??????????????擅長(zhǎng)/熟識(shí)該業(yè)務(wù)領(lǐng)域的人；
??????????????擅長(zhǎng)/熟識(shí)該技術(shù)領(lǐng)域的人；
????????○?期望能知曉該 PR 的人：
??????????????會(huì)受到該代碼改動(dòng)影響的人；
??????????????近期正在學(xué)習(xí)該業(yè)務(wù)/技術(shù)領(lǐng)域的人；
? ????收到Comment及時(shí)跟進(jìn)
????????○?修改后及時(shí)回復(fù) comment 或 refresh assignee，不要指望其他人能一直蹲守你的更新或修改
????????○?出現(xiàn)意見分歧，避免過度依賴 Comment 交流，線下溝通優(yōu)先，其次是 IM
????????○?若因時(shí)間或計(jì)劃問題無法在當(dāng)前 PR 中完成修改，達(dá)成一致后創(chuàng)建 Tech Debt Ticket 備忘
????????○?盡可能避免在已經(jīng)Approve的PR上進(jìn)行無關(guān)修改，以免給Reviewer造成不必要的重復(fù)工作
一句話總結(jié)：對(duì)自己提出的每一個(gè) PR 負(fù)責(zé)
2. 作為Reviewer
? ????主動(dòng)閱讀 Description
????????○?作為普通 Reviewer，有必要了解 PR 的上下文
????????○?作為業(yè)務(wù)/技術(shù)領(lǐng)域相關(guān)者，有必要了解代碼及邏輯變更情況
? ????得當(dāng)?shù)?Comment
????????○?表述簡(jiǎn)潔清晰無歧義
????????○?通常應(yīng)具有目的性：明確知道自己想要的回復(fù)是哪一種，是希望 Author 改正問題？補(bǔ)充上下文？解答疑惑？或是說明計(jì)劃？目的不明的 Comment 只會(huì)造成不必要的反復(fù)溝通
????????○?不僅可以指出問題，同樣可以請(qǐng)教問題
????????○?給出肯定或表?yè)P(yáng)的 Comment
????????○?無需過于正式：Comment 的數(shù)量并不會(huì)用于反映工作量，因而任何形式不會(huì)對(duì)雙方工作造成影響的 Comment 都是可行且值得鼓勵(lì)的
? ????Comment 后及時(shí)跟進(jìn)
????????○?及時(shí)回復(fù) Author 的追問
????????○?Author 修改后及時(shí) Resolve 或 Approve
? ????及時(shí)給出反饋
????????○?根據(jù)實(shí)際情況，給出 Approve，Comment 或 Request Change
????????○?謹(jǐn)慎給出 Approve：Review 代碼后，若有足夠把握，可以給出 Approve；若存在疑慮（不了解相關(guān)業(yè)務(wù)、底層邏輯），也應(yīng)給出 Comment 表明 Review 完成，不應(yīng)讓 Author 無止盡的空等
? ????不要成為 Blocker
????????○ 僅有的 Repo Code Owner、點(diǎn)名指定的 Reviewer（業(yè)務(wù)/技術(shù)領(lǐng)域相關(guān)者），必須要給出反饋
????????○?Request Change 的 Reviewer，必須要及時(shí)跟進(jìn)
一句話總結(jié)：對(duì)自己給出的每一個(gè) Comment 和 Approve 負(fù)責(zé)
3. 參與者應(yīng)有的共識(shí)
? ????Code Review 的主要目的不應(yīng)是為了發(fā)現(xiàn) Bug，也不應(yīng)是為了檢查代碼風(fēng)格和規(guī)范
? ????Code Review 是溝通的一種形式，作用是相互的
? ????Code Review 時(shí)不要吝嗇你的贊美之詞
? ????Code Review 時(shí)不可固執(zhí)己見
? ????Code Review 時(shí)應(yīng)正面且友善
最后，
還有幾句要說：
看到這兒大家應(yīng)該都能感覺到，Author 要做的事情和 Reviewer 要做的事情基本都是相輔相成，兩邊缺一不可，說到底，推動(dòng) Code Review 需要整個(gè) Team 甚至公司一起努力，但需要努力，并不意味著“不用很麻煩很累”是 Fake News，只要 Code Review 成為公司的一種文化、一種習(xí)慣，所有的一切都會(huì)變得理所當(dāng)然，且有趣。
“卓派前端工作志，聚焦實(shí)用前端技術(shù)，讓編程更有趣！”
前端技術(shù)組 @ 西安卓派科技 NEXT Trucking —?拉勾?|?Boss?|?知乎?|?掘金?|?簡(jiǎn)書
如果覺得本文對(duì)你有幫助的話，快來關(guān)注我們吧！
