背景

第一次參加CodeReview不知道該如何去做，也不知道為什么去做，后來(lái)參加多了，慢慢了解了CodeReview的意義，也同時(shí)發(fā)現(xiàn)CodeReview的效率問(wèn)題：

• 有時(shí)候會(huì)發(fā)現(xiàn)一個(gè)CodeReview時(shí)間很長(zhǎng)，參與者會(huì)覺(jué)得煎熬和浪費(fèi)時(shí)間；
• 有時(shí)候不太了解對(duì)方評(píng)審的東西，沒(méi)法跟上大家的思路，影響效率；
• 有時(shí)候走查的代碼量太大了，無(wú)法做到詳細(xì)走查；
• 有時(shí)候會(huì)看到有些人無(wú)所事事、精神不集中、不發(fā)言，會(huì)影響效果。

寫(xiě)這篇文章，希望本文中的一些建議能夠緩解上述問(wèn)題，能使新人更快的了解CodeReview的意義和方法，有經(jīng)驗(yàn)的人能夠更加快速有效的進(jìn)行CodeReview。

CodeReview的目標(biāo)和原則

CodeReview的目的是提升代碼質(zhì)量，盡早發(fā)現(xiàn)潛在缺陷與BUG，降低修復(fù)成本，同時(shí)促進(jìn)團(tuán)隊(duì)內(nèi)部知識(shí)共享，幫助更多人更好地理解系統(tǒng)。建議CodeReview的原則如下：

• 發(fā)現(xiàn)代碼的正確性

代碼審查用意是在代碼提交前找到其中的問(wèn)題——你要發(fā)現(xiàn)的是它的正確性。在代碼審查中最常犯的錯(cuò)誤—幾乎每個(gè)新手都會(huì)犯的錯(cuò)誤是，審查者根據(jù)自己的編程習(xí)慣來(lái)評(píng)判別人的代碼。

• 不僅是在Review Code，更是在分享和學(xué)習(xí)

Code Review最重要的是講解者分享業(yè)務(wù)流程和設(shè)計(jì)思路，參與者通過(guò)這些講解獲得這些信息，使得更多人理解這個(gè)系統(tǒng)，提升團(tuán)隊(duì)整體水平，使得團(tuán)隊(duì)維護(hù)代碼的能力提升。

• 高效迅速完成CodeReview

我們不能為了應(yīng)付匆匆忙忙的進(jìn)行一次代碼審查，效率也是很重要的，如果不能保證Code Review目的實(shí)現(xiàn)，那么評(píng)審便是徒勞的。

如何高效完成CodeReview？

參與者要檢查設(shè)計(jì)的合理性以及業(yè)務(wù)邏輯是否錯(cuò)誤，檢查代碼可讀性；講解者要想辦法分享設(shè)計(jì)、技術(shù)、經(jīng)驗(yàn)等知識(shí)。

1.檢查設(shè)計(jì)的合理性和業(yè)務(wù)邏輯的正確性：

• 代碼的設(shè)計(jì)是否符合設(shè)計(jì)要求：
  • 如果存在代碼和設(shè)計(jì)有出入的地方需要問(wèn)詢(xún)?yōu)槭裁匆儎?dòng)，因?yàn)檫@些變動(dòng)有可能是出于開(kāi)發(fā)者在真正設(shè)計(jì)代碼時(shí)候的深入考慮，或者是由于一時(shí)大意出現(xiàn)偏差。
• 業(yè)務(wù)邏輯是否正確：
  • 業(yè)務(wù)流程是否按照詳細(xì)設(shè)計(jì)的流程走，不要出現(xiàn)原本是先A流程后B流程而設(shè)計(jì)的時(shí)候出現(xiàn)先B后A，或者丟失流程。
  • 某些傳入?yún)?shù)是否合理：判斷某些接口的參數(shù)輸入是否是冗余的，比如輸入A字段可以滿(mǎn)足A接口里面的所有操作，那么多輸入一個(gè)B就冗余的。
  • 數(shù)據(jù)庫(kù)字段的設(shè)計(jì)，數(shù)據(jù)庫(kù)的設(shè)計(jì)是對(duì)實(shí)際業(yè)務(wù)的映射，我們要保證每一個(gè)字段的出現(xiàn)都反應(yīng)實(shí)際業(yè)務(wù)并且經(jīng)過(guò)合理性的驗(yàn)證，比如設(shè)計(jì)table1的時(shí)候A字段在table2中已經(jīng)出現(xiàn)，并且A和B表有相應(yīng)的關(guān)聯(lián)，那么要注意A字段對(duì)于table1的冗余是否有合理性，如果沒(méi)有合理的說(shuō)服性可以去掉A，而節(jié)省對(duì)A字段的維護(hù)成本（存儲(chǔ)空間，更新操作等）。
  • 某些判斷是否合理，比如某些參數(shù)的輸入金額是否可以為0的判斷等等。
  • 系統(tǒng)交互是否合理，比如在代碼設(shè)計(jì)的時(shí)候沒(méi)有關(guān)注考慮系統(tǒng)交互的順序而造成有些信息不能獲取到；比如獲取支付方式的費(fèi)率信息必須要等待支付的時(shí)候才能拿到，那么獲取這些信息就應(yīng)該放在pay_trans的時(shí)候而不是create_trans，大多數(shù)這種問(wèn)題其實(shí)都是詳細(xì)設(shè)計(jì)時(shí)出現(xiàn)的，代碼評(píng)審階段比較少見(jiàn)。
  • 是否有異常處理機(jī)制，一個(gè)好的代碼設(shè)計(jì)應(yīng)該考慮各種異常并對(duì)相應(yīng)的異常做出合理的處理，比如接口的可重入，當(dāng)代碼檢測(cè)到有重入的這種情況，怎樣去做這種異常處理使得調(diào)用方能捕捉的這些異常而進(jìn)行后面的處理。
• 關(guān)注業(yè)務(wù)可拓展性：
  • 我們的業(yè)務(wù)在不斷的發(fā)展，每一個(gè)項(xiàng)目設(shè)計(jì)都會(huì)影響后續(xù)業(yè)務(wù)的拓展，一個(gè)好的設(shè)計(jì)應(yīng)該考慮到后續(xù)業(yè)務(wù)的發(fā)展，而盡量避免定制化的設(shè)計(jì)。
• 關(guān)注使用到的數(shù)據(jù)結(jié)構(gòu)、設(shè)計(jì)模式和代碼性能：
  • 一個(gè)好的數(shù)據(jù)結(jié)構(gòu)和設(shè)計(jì)模式可以增加代碼的可維護(hù)性安全性和效率等，比如我們?cè)谠O(shè)計(jì)的時(shí)候要考慮到不同的場(chǎng)景選擇什么樣的數(shù)據(jù)結(jié)構(gòu)，有時(shí)候我們會(huì)糾結(jié)于用map還是用hash_map，這時(shí)候我們要根據(jù)具體的情況具體分析；
  • 當(dāng)我們?cè)O(shè)計(jì)代碼的時(shí)候如果能用上系統(tǒng)提供的函數(shù)那么最好不要自己去寫(xiě)，比如自己實(shí)現(xiàn)一個(gè)鏈表的時(shí)候是否可以想到用系統(tǒng)庫(kù)提供的list_head以確保鏈表結(jié)構(gòu)的正確性；
  • 某些設(shè)計(jì)如果能套用設(shè)計(jì)模式會(huì)讓設(shè)計(jì)更加美觀也讓閱讀者更加明了；出于對(duì)系統(tǒng)性能的考量，我們要關(guān)注編寫(xiě)代碼對(duì)系統(tǒng)的開(kāi)銷(xiāo)，包括使用的算法是否合理，以及對(duì)某些比較耗時(shí)的操作比如數(shù)據(jù)庫(kù)的操作要加以關(guān)注。

2.檢查代碼可讀性和可維護(hù)性：

• 如果代碼的可讀性強(qiáng)，那么維護(hù)起來(lái)也就方便很多；一個(gè)好的代碼規(guī)范和編碼風(fēng)格會(huì)節(jié)省大家對(duì)代碼的理解時(shí)間，減少維護(hù)成本；雖然我們有編程規(guī)范檢查工具，但有些內(nèi)容檢查不出來(lái)，是需要靠大家去規(guī)范的。
• 關(guān)注代碼注釋?zhuān)何覀冊(cè)诰帉?xiě)函數(shù)和進(jìn)行邏輯判斷的時(shí)候最好要標(biāo)注一下這個(gè)函數(shù)或者這段判斷是用來(lái)做什么的；做了這種注釋的好處，一來(lái)當(dāng)別人閱讀這段代碼的時(shí)候看到你的注釋以后就會(huì)根據(jù)你的思路快速理解代碼，甚至不閱讀直接跳過(guò)；二來(lái)防止自己由于長(zhǎng)時(shí)間不閱讀代碼而忘記這段代碼的用途。
• 關(guān)注命名規(guī)范：雖然我們有自己的編碼規(guī)范，但是這種規(guī)范只是限制了使用駝峰命名法還是其他命名法；而好的命名風(fēng)格應(yīng)該是看到變量或者函數(shù)名字就能“望文生義”，畢竟我們不能把自己寫(xiě)的所有代碼都做注釋。
• 關(guān)注重復(fù)代碼：如果出現(xiàn)大量的重復(fù)性代碼，要考慮將這些代碼抽象出公用函數(shù)，以減少代碼量并增強(qiáng)代碼可讀性。
• 關(guān)注繁瑣的邏輯：如果一個(gè)簡(jiǎn)單的功能卻對(duì)應(yīng)大篇幅的代碼，要考慮一下是不是有比較簡(jiǎn)單的實(shí)現(xiàn)方式，因?yàn)檫^(guò)于復(fù)雜的代碼會(huì)給后來(lái)者的維護(hù)帶來(lái)麻煩；如果沒(méi)有簡(jiǎn)略的辦法，一定要把注釋寫(xiě)好。

3.分享設(shè)計(jì)、技術(shù)、知識(shí)和經(jīng)驗(yàn)

• 在代碼審查的過(guò)程中，大家往往把關(guān)注點(diǎn)放在發(fā)現(xiàn)代碼的不足上，忽略了代碼評(píng)審過(guò)程中的設(shè)計(jì)思想、技術(shù)方法、業(yè)務(wù)知識(shí)的傳播，我覺(jué)得這些內(nèi)容也是非常重要的，也需要同時(shí)關(guān)注。
• 評(píng)審者在自己的代碼時(shí)會(huì)深入業(yè)務(wù)流程，參與這可以看到評(píng)審代碼的一些算法、數(shù)據(jù)結(jié)構(gòu)、設(shè)計(jì)模式甚至是系統(tǒng)架構(gòu)等知識(shí)以及評(píng)審者在編碼過(guò)程中踩過(guò)的坑；通過(guò)這些信息參與者可以提升自己的業(yè)務(wù)水平和技術(shù)能力使得整個(gè)團(tuán)隊(duì)的水平得到提高。
• 參與者除了要有這種學(xué)習(xí)意識(shí)外，評(píng)審者也要想辦法讓參與者更加快速高效的去理解代碼中傳播的知識(shí)，這樣能幫助提升Review速度，所以建議評(píng)審者能簡(jiǎn)單介紹一下項(xiàng)目的背景以及詳細(xì)設(shè)計(jì)，這些信息的介紹有以下好處：
  • 首先，代碼的設(shè)計(jì)是按照詳細(xì)設(shè)計(jì)來(lái)執(zhí)行的，但是設(shè)計(jì)者在真正code的時(shí)候會(huì)出現(xiàn)一些變動(dòng)，這些變動(dòng)要給大家一個(gè)同步；
  • 其次，參與過(guò)詳細(xì)設(shè)計(jì)的人可能由于沒(méi)有直接參與的code，時(shí)間長(zhǎng)會(huì)忘記之前詳細(xì)設(shè)計(jì)的流程，簡(jiǎn)單介紹之后就會(huì)讓參與者想起，方便參與者的理解；
  • 第三，對(duì)于沒(méi)參與詳細(xì)設(shè)計(jì)的同學(xué)，在簡(jiǎn)單介紹過(guò)這些信息后，可以有個(gè)大致了解，不然整個(gè)評(píng)審過(guò)程會(huì)很煎熬；
  • 所以，如果參與者對(duì)代碼的信息不理解，會(huì)造成參與者理解代碼的難度，也就不能提出有建設(shè)性的意見(jiàn)，同時(shí)也難以學(xué)到評(píng)審中傳播的知識(shí)；這一點(diǎn)在之前的評(píng)審中是比較容易被大家忽略的，尤其是在跨團(tuán)隊(duì)代碼評(píng)審時(shí)，準(zhǔn)備不足和經(jīng)驗(yàn)不足的同學(xué)是很難理解對(duì)方在講什么的。
• 講解code的時(shí)候最好是以接口功能為單位去講解
  • 如果評(píng)審者一下子把所有的詳細(xì)設(shè)計(jì)都講解完，可能會(huì)因?yàn)樾畔⒘勘容^大，或者設(shè)計(jì)到一些細(xì)節(jié)問(wèn)題，參與者不能有效的記住或理解也會(huì)影響評(píng)審的速度和效率；
  • 評(píng)審者可以在講解的過(guò)程中分享一下自己踩過(guò)的坑，參與者可以隨時(shí)根據(jù)自己發(fā)現(xiàn)的問(wèn)題進(jìn)行討論。

如何迅速完成CodeReview？

所謂的迅速就是節(jié)省時(shí)間，只要我們盡量避免一些意義不大的事情就能節(jié)省時(shí)間，加快評(píng)審速度，要做到這點(diǎn)建議大家盡量不要做以下這些事情：

1.不要刻意地去尋找代碼bug

• 有些代碼的邏輯是比較復(fù)雜的，如果是很容易就發(fā)現(xiàn)的缺陷，大多數(shù)情況下評(píng)審者自己在編碼過(guò)程就會(huì)發(fā)現(xiàn)，那么剩下不容易發(fā)現(xiàn)的缺陷要發(fā)現(xiàn)也會(huì)花費(fèi)較多的時(shí)間，這些問(wèn)題可以交給測(cè)試人員去發(fā)現(xiàn)；
• 如果參與者刻意去找bug會(huì)造成顧此失彼，忽略更重要的東西；當(dāng)然，有些bug你可能一眼就看出來(lái)了，那提出來(lái)就再好不過(guò)了。

2.不要按照自己的編程風(fēng)格去評(píng)論別人的代碼

• 有些人參與者比較自信，對(duì)自己寫(xiě)得代碼感覺(jué)很滿(mǎn)意，所以有時(shí)候就會(huì)根據(jù)自己熟悉的編碼語(yǔ)言或者編碼風(fēng)格去評(píng)論別人的代碼；
• 作為參與者，只要覺(jué)得評(píng)審者的代碼符合命名要求和設(shè)計(jì)要求就可以了，但假如評(píng)審者的代碼缺陷很明顯，可以提出帶大家進(jìn)行討論。

3.不要帶著抨擊和質(zhì)疑別人能力的心態(tài)去進(jìn)行代碼評(píng)審

• 有時(shí)候參與者可能心情不好，或者感覺(jué)對(duì)方是新人就忍不住會(huì)抨擊對(duì)方的代碼，這樣會(huì)比較容易在模棱兩可的問(wèn)題上浪費(fèi)時(shí)間；
• 參與者可能認(rèn)為A方法好，評(píng)審者可能認(rèn)為B方法也不壞，這樣就會(huì)造成沒(méi)有必要的爭(zhēng)論而浪費(fèi)時(shí)間。

4.不要在不確定的問(wèn)題上爭(zhēng)來(lái)爭(zhēng)去

• 大家在討論的時(shí)候如果某些問(wèn)題討論一段時(shí)間以后仍然沒(méi)有結(jié)論，或者需要第三方確認(rèn)或者評(píng)審者不能馬上理解參與者提出的意見(jiàn)時(shí)，不要花太多時(shí)間討論這些問(wèn)題；
• 把這些問(wèn)題先記錄下來(lái)，等會(huì)議結(jié)束后評(píng)審者可以與參與者進(jìn)行線(xiàn)下討論，同時(shí)將這些問(wèn)題根據(jù)自己的理解進(jìn)行解決，之后給大家一個(gè)反饋即可，這樣可以節(jié)省很多時(shí)間。

5.不要聽(tīng)不進(jìn)別人的意見(jiàn)

• 有些評(píng)審者比較固執(zhí)，不愿意接受大家的意見(jiàn)，會(huì)造成一些不必要的爭(zhēng)端和討論，浪費(fèi)時(shí)間；
• 當(dāng)然，有時(shí)候參與者的意見(jiàn)不見(jiàn)得是最好的，作為評(píng)審者將其作為一個(gè)參照的方向和視角，如果存在爭(zhēng)論，這些建議也可以做成會(huì)議記錄，評(píng)審者私下和建議提出者討論以后給大家一個(gè)結(jié)論。

6.參與者最好不要自己都沒(méi)想明白就提意見(jiàn)

• 如果參與者自己沒(méi)有想明白的事情就去提意見(jiàn)，那么評(píng)審者反問(wèn)的時(shí)候會(huì)浪費(fèi)大家的時(shí)間；
• 參與者可以先將自己的想法大致記下來(lái)，自己想清楚了之后再提給評(píng)審者也是節(jié)省時(shí)間的辦法。

總結(jié)

綜上，給大家介紹了一些如何進(jìn)行高效迅速的CodeReview一些思考方向，這些方式是否適用還需要大家在實(shí)踐過(guò)程中進(jìn)行驗(yàn)證，也需要根據(jù)不同團(tuán)隊(duì)的實(shí)際情況做相應(yīng)的調(diào)整，我們最終的目的是希望CoderReview能夠有效而迅速，一方面提升代碼質(zhì)量本身，另一方面也可以創(chuàng)造一個(gè)良好的學(xué)習(xí)氛圍互相支持提升團(tuán)隊(duì)的整體代碼水平。

總結(jié)

以上是生活随笔為你收集整理的如何进行高效迅速的CodeReview的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。