[[384753]]

本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。

Hello 大家好我是阿粉，代碼 Review 相信大家一定不會(huì)陌生，但是真正在日常工作中能使用并且堅(jiān)持執(zhí)行下去的公司或者團(tuán)隊(duì)，阿粉覺得并不多，但是代碼 Review 的好處大家都是有目共睹的，很多招聘崗位上面都有這樣的要求，堅(jiān)持執(zhí)行代碼 Review 對(duì)團(tuán)隊(duì)，對(duì)公司是很有好處的，特別是對(duì)寫代碼的同事!每個(gè)一起閱讀代碼的同事都會(huì)提出一些自己的建議 ，這些建議都是很寶貴的資源，往往都會(huì)有很大的收獲。

那么如何做好一場(chǎng)代碼 Review 呢?想要做好一場(chǎng)合格的代碼 Review，首先我們需要知道代碼 Review 的過程中都有哪些角色以及需要怎樣的流程。

角色

• 代碼的作者 Author;
• 閱讀代碼的同事 Reviewer;
• 主持人 Host;
• 記錄員 Recorder。

流程

1. 提前一天發(fā)送 Review 代碼郵件給相關(guān)人員，確定 Host 和 Recorder;
2. 由 Host 主持 Review 會(huì)議;
3. 由 Reviewer 和 Author 進(jìn)行代碼走讀;
4. 由 Recorder 進(jìn)行改進(jìn)記錄。

在做代碼 Review 之前 Author 需要提前一天需要發(fā)正式郵件給相關(guān)人員，并且將需要被 Review 的代碼通過郵件附件的方式，發(fā)送給相關(guān)的 Reviewer 讓他們提前閱讀，這樣有助于 Review 的時(shí)候可以更高效的進(jìn)行。并且提前溝通好代碼 Review 的會(huì)議 Host 和 Recorder。Host 在會(huì)議過程中負(fù)責(zé)組織大家發(fā)言和維護(hù)秩序，讓代碼 Review 更高效;Recorder 則負(fù)責(zé)將整個(gè) Review 過程中提到的需要優(yōu)化和改進(jìn)的點(diǎn)進(jìn)行文檔形式的記錄，記錄的信息需要言簡(jiǎn)意賅，將哪個(gè)文件哪一行代碼，問題是什么，建議怎么優(yōu)化都需要記下來，并且在會(huì)議結(jié)束過后以郵件的形式發(fā)送給 Author 和抄送大家。

Review

在進(jìn)行代碼 Review 的時(shí)候 Author 需要從文件的第一行開始進(jìn)行一行行的代碼走讀，對(duì)每一行的代碼進(jìn)行描述，這里需要注意的是不要認(rèn)為某個(gè)功能很簡(jiǎn)單，就可以一句帶過，往往很多線上 Bug 都是因?yàn)檫@種忽略導(dǎo)致的。走讀代碼的時(shí)候 Author 需要解釋清楚每一行代碼的含義，說明這行代碼是干嘛的，為什么要這樣寫。Reviewer 則需要根據(jù) Author 的描述再結(jié)合自己之前閱讀代碼的理解進(jìn)行提問或者改進(jìn)方案。

代碼走讀的過程持續(xù)進(jìn)行的同時(shí) Recorder 需要及時(shí)記錄需要改進(jìn)的內(nèi)容，并把提出的優(yōu)化方案記錄下來。代碼走讀的過程是整個(gè) Review 的核心，在這個(gè)環(huán)節(jié)中我們需要注意很多東西。知乎上面有個(gè)提問大家的公司的 Code Review 都是怎么做的?遇到過哪些問題?，上面有個(gè)回答提出的幾個(gè)點(diǎn)很不錯(cuò)，我覺得有必要分享給大家，對(duì)我們的整個(gè) Review 會(huì)很有幫助，特別是當(dāng)自己是 Reviewer 的時(shí)候，需要格外注意。

• 對(duì)事不對(duì)人。要記住大家都是同事，今天自己是 Reviewer 來對(duì)別人的代碼進(jìn)行 Review，哪天別人就會(huì)對(duì)自己的代碼進(jìn)行 Review，所以在整個(gè)代碼 Review 的環(huán)節(jié)中，我們可以提出自己的建議，但是需要注意自己的用詞和語氣，雖然程序員有鄙視鏈，并且都認(rèn)為別人的代碼垃圾，但是這種時(shí)候不能瞎說，容易打架的，還是要謙虛點(diǎn)。
• 用正面的詞匯進(jìn)行評(píng)價(jià)。跟上面說的一樣，我們需要用正面的詞匯進(jìn)行評(píng)價(jià)代碼，考慮 Author 的情緒，即使代碼寫的不好。這個(gè)很好理解，畢竟代碼 Review 是在很多人面前的，對(duì) Author 來說，讓別人看自己寫的代碼就像在別人面前裸奔一樣，所以我們不僅要提出意見在好的地方我們也要進(jìn)行正向的表揚(yáng)。
• 如果有更好的方案一定要提出來。代碼 Review 的目的就是優(yōu)化代碼，找出代碼中的隱藏 BUG 以及邏輯問題。所以如果發(fā)現(xiàn)了代碼有任何不優(yōu)雅的地方或者會(huì)出現(xiàn)問題的地方一定要及時(shí)的提出來，不要擔(dān)心自己說的不對(duì)，或者考慮 Author 的面子問題，不指出來，提供更好的解決方案，讓大家一起進(jìn)步。
• Review 會(huì)議是 Review 代碼，而不是討論需求。這一點(diǎn)也是很容易被帶偏的一個(gè)點(diǎn)，經(jīng)常我們會(huì)發(fā)現(xiàn)在 Review 的過程中，慢慢的就變成了討論需求了，這種情況一定要避免發(fā)生，不然整個(gè)代碼 Review 環(huán)節(jié)就是失敗的，無法進(jìn)行下去了。所以 Author 在發(fā)起代碼 Review 邀請(qǐng)時(shí)一定要確保自己理解的需求是正確的，避免浪費(fèi)大家的時(shí)間。
• 高效的進(jìn)行。進(jìn)行代碼 Review 的時(shí)候我們需要注意一定要高效，如何做到高效就需要每個(gè)人都做好相應(yīng)的準(zhǔn)備，Author 需要對(duì)自己的代碼進(jìn)行熟練的講解，Reviewer 需要在參加會(huì)議之前將需要 Review 的代碼看一下，提前找到可能隱藏的 Bug，對(duì)于不懂地方需要做好記錄，方便開會(huì)的時(shí)候及時(shí)指出。
• 避免形式主義。這一點(diǎn)也是被很多小伙伴忽略的一點(diǎn)，隨著代碼 Review 的次數(shù)越來越多，很多小伙伴可能就把這個(gè)當(dāng)成一個(gè)任務(wù)，慢慢的就變成了形式主義，而不是注重實(shí)際，每次代碼 Review 的時(shí)候就很隨意，長期這樣下去對(duì)公司，團(tuán)隊(duì)以及自己都不好，而且還浪費(fèi)時(shí)間。

總結(jié)阿粉今天給大家介紹了一個(gè)如何做一個(gè)合格的代碼 Review，當(dāng)然這只是阿粉自己的一些見解，大家有任何意見可以在評(píng)論區(qū)給我們留言，大家一起交流學(xué)習(xí)。