如何編寫代碼Review

這篇文章主要介紹“如何編寫代碼Review”，在日常操作中，相信很多人在如何編寫代碼Review問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何編寫代碼Review”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

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

角色

• 代碼的作者 Author;

• 閱讀代碼的同事 Reviewer;

• 主持人 Host;

• 記錄員 Recorder。

流程

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 提前一天發(fā)送 Review 代碼郵件給相關(guān)人員，確定 Host 和 Recorder;

3. 由 Host 主持 Review 會議;

4. 由 Reviewer 和 Author 進(jìn)行代碼走讀;

5. 由 Recorder 進(jìn)行改進(jìn)記錄。

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

Review

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

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

• 對事不對人。要記住大家都是同事，今天自己是 Reviewer 來對別人的代碼進(jìn)行 Review，哪天別人就會對自己的代碼進(jìn)行 Review，所以在整個代碼  Review  的環(huán)節(jié)中，我們可以提出自己的建議，但是需要注意自己的用詞和語氣，雖然程序員有鄙視鏈，并且都認(rèn)為別人的代碼垃圾，但是這種時候不能瞎說，容易打架的，還是要謙虛點(diǎn)。

• 用正面的詞匯進(jìn)行評價。跟上面說的一樣，我們需要用正面的詞匯進(jìn)行評價代碼，考慮 Author 的情緒，即使代碼寫的不好。這個很好理解，畢竟代碼 Review  是在很多人面前的，對 Author 來說，讓別人看自己寫的代碼就像在別人面前裸奔一樣，所以我們不僅要提出意見在好的地方我們也要進(jìn)行正向的表揚(yáng)。

• 如果有更好的方案一定要提出來。代碼 Review 的目的就是優(yōu)化代碼，找出代碼中的隱藏 BUG  以及邏輯問題。所以如果發(fā)現(xiàn)了代碼有任何不優(yōu)雅的地方或者會出現(xiàn)問題的地方一定要及時的提出來，不要擔(dān)心自己說的不對，或者考慮 Author  的面子問題，不指出來，提供更好的解決方案，讓大家一起進(jìn)步。

• Review 會議是 Review 代碼，而不是討論需求。這一點(diǎn)也是很容易被帶偏的一個點(diǎn)，經(jīng)常我們會發(fā)現(xiàn)在 Review  的過程中，慢慢的就變成了討論需求了，這種情況一定要避免發(fā)生，不然整個代碼 Review 環(huán)節(jié)就是失敗的，無法進(jìn)行下去了。所以 Author 在發(fā)起代碼  Review 邀請時一定要確保自己理解的需求是正確的，避免浪費(fèi)大家的時間。

• 高效的進(jìn)行。進(jìn)行代碼 Review 的時候我們需要注意一定要高效，如何做到高效就需要每個人都做好相應(yīng)的準(zhǔn)備，Author  需要對自己的代碼進(jìn)行熟練的講解，Reviewer 需要在參加會議之前將需要 Review 的代碼看一下，提前找到可能隱藏的  Bug，對于不懂地方需要做好記錄，方便開會的時候及時指出。

• 避免形式主義。這一點(diǎn)也是被很多小伙伴忽略的一點(diǎn)，隨著代碼 Review  的次數(shù)越來越多，很多小伙伴可能就把這個當(dāng)成一個任務(wù)，慢慢的就變成了形式主義，而不是注重實(shí)際，每次代碼 Review  的時候就很隨意，長期這樣下去對公司，團(tuán)隊以及自己都不好，而且還浪費(fèi)時間。

到此，關(guān)于“如何編寫代碼Review”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！