Code Review 環(huán)節(jié)實(shí)施秘訣！

眾所周知，Code Review 是開(kāi)發(fā)過(guò)程中一個(gè)非常重要的環(huán)節(jié)，但是很多公司或者團(tuán)隊(duì)是沒(méi)有這一環(huán)節(jié)的，今天筆者結(jié)合自己所在團(tuán)隊(duì)，淺談 Code Review 的價(jià)值及如何實(shí)施。

1. Code Review 的價(jià)值

許多團(tuán)隊(duì)沒(méi)有 Code Review 環(huán)節(jié)，或者因?yàn)樽非箜?xiàng)目快速上線，認(rèn)為 CR 浪費(fèi)時(shí)間；或者團(tuán)隊(duì)成員缺少 CR 觀念，認(rèn)為 CR 的價(jià)值并不大。所以想要推動(dòng) CR 在團(tuán)隊(duì)中的實(shí)施，最最重要的一點(diǎn)便是增強(qiáng)團(tuán)隊(duì)成員對(duì) CR 環(huán)節(jié)的認(rèn)同感。

Code Review 環(huán)節(jié)，它更加依賴于團(tuán)隊(duì)成員的主觀能動(dòng)性，只有團(tuán)隊(duì)成員對(duì)其認(rèn)可，他們才會(huì)積極地參入這一環(huán)節(jié)，CR 的價(jià)值才能最大化的體現(xiàn)。如果團(tuán)隊(duì)成員不認(rèn)可 CR，即使強(qiáng)制設(shè)置了 CR 流程，也是形同虛設(shè)，反而可能阻礙正常開(kāi)發(fā)流程的效率。那么如何讓團(tuán)隊(duì)成員認(rèn)可 CR 環(huán)節(jié)呢，自然是讓他們意識(shí)到 CR 的價(jià)值，然后就會(huì)…… 真香！

1.1 提升團(tuán)隊(duì)代碼質(zhì)量

隨著團(tuán)隊(duì)規(guī)模的擴(kuò)大和項(xiàng)目的迭代升級(jí)，團(tuán)隊(duì)之間的信息透明度會(huì)越來(lái)越低，項(xiàng)目的可維護(hù)性也會(huì)越來(lái)越差，可能引發(fā)如下一系列問(wèn)題：

1. 已有的 utils 方法，重復(fù)造輪子
2. 代碼過(guò)于復(fù)雜，缺少必要注釋，后人難以維護(hù)
3. 目錄結(jié)構(gòu)五花八門，雜亂不堪
   ……
   合理的 CR 環(huán)節(jié)，可以有效地把控每次提交的代碼質(zhì)量，不至于讓項(xiàng)目的可維護(hù)性隨著版本迭代和時(shí)間推移變得太差，這也是 CR 的首要目的。CR 環(huán)節(jié)并不會(huì)降低開(kāi)發(fā)效率，就一次代碼提交來(lái)說(shuō)，也許部分人認(rèn)為 CR 可能花費(fèi)了時(shí)間，但是有效的 CR 給后人擴(kuò)展和維護(hù)時(shí)所節(jié)省的時(shí)間是遠(yuǎn)超于此的。

1.2 團(tuán)隊(duì)技術(shù)交流

Reviewer 和 Reviewee，在參與 CR 的過(guò)程中，都是可以收獲到許多知識(shí)，進(jìn)行技術(shù)交流的。

1. 有利于幫助新人快速成長(zhǎng)，團(tuán)隊(duì)有新人加入時(shí)（如實(shí)習(xí)生和校招生），往往需要以為導(dǎo)師帶領(lǐng)一段時(shí)間，通過(guò) CR 環(huán)節(jié)，可以使導(dǎo)師最直接的了解到新人開(kāi)發(fā)過(guò)程中所遇到的問(wèn)題，作出相應(yīng)的指導(dǎo)。
2. 通過(guò) CR 環(huán)節(jié)，團(tuán)隊(duì)成員可以了解他人的業(yè)務(wù)，而不局限于自己的所負(fù)責(zé)的業(yè)務(wù)范圍。項(xiàng)目發(fā)現(xiàn)問(wèn)題時(shí)，可以迅速定位到相關(guān)業(yè)務(wù)的負(fù)責(zé)人進(jìn)行修改。同時(shí)若有的團(tuán)隊(duì)成員離職后，也可以減少業(yè)務(wù)一人負(fù)責(zé)所帶來(lái)的后期維護(hù)困難。
3. 學(xué)習(xí)他人的優(yōu)秀代碼。通過(guò) CR 環(huán)節(jié)，可以迅速接觸到團(tuán)隊(duì)成員在項(xiàng)目中解決某些問(wèn)題的優(yōu)秀代碼，或者使用的一些你所未接觸過(guò)的一些 api 等。

1.3 保證項(xiàng)目的統(tǒng)一規(guī)范

既然要進(jìn)行 CR，首先要對(duì)項(xiàng)目的規(guī)范制定要求，包括編碼風(fēng)格規(guī)范、目錄結(jié)構(gòu)規(guī)范、業(yè)務(wù)規(guī)范等等。一方面，統(tǒng)一的項(xiàng)目規(guī)范才能保證項(xiàng)目的代碼質(zhì)量，提高項(xiàng)目的質(zhì)量和可維護(hù)性；另一方面，在大家熟悉了統(tǒng)一的規(guī)范后，能夠提升 CR 的效率，節(jié)省時(shí)間。

2. Code Review 的實(shí)踐

關(guān)于 Code Review 的實(shí)踐，要考慮的包括 CR 所花費(fèi)的時(shí)間、CR 的形式、何時(shí)進(jìn)行 CR 等等。

2.1 預(yù)留 CR 的時(shí)間

首先不得不承認(rèn)，CR 環(huán)節(jié)是要耗費(fèi)一定時(shí)間的，所以在項(xiàng)目排期中，不僅要考慮開(kāi)發(fā)、聯(lián)調(diào)、提測(cè)、改 bug 等時(shí)間，還要預(yù)留出 CR 的時(shí)間。包括擔(dān)任 Reviewer 和 Reviewee 角色的時(shí)間都要考慮。
另外如果遇到的需求比較復(fù)雜，為了避免因?yàn)?CR 過(guò)程導(dǎo)致代碼需要大量修改，最好提前和團(tuán)隊(duì)成員溝通好需求的設(shè)計(jì)和結(jié)果思路。

2.2 CR 的形式

我所見(jiàn)過(guò)的 CR 大多有兩種形式。一種是設(shè)立一個(gè)特定時(shí)間，例如每周或者每半月等等，團(tuán)隊(duì)成員一起對(duì)之前的 Merge Request 進(jìn)行 CR；另一種是對(duì)每次的 Merge Request 都進(jìn)行 CR。

我個(gè)人更偏向于后者。第一種定期 CR，Merge Request 的數(shù)量太多，不太可能對(duì)所有的 MR 進(jìn)行 CR，如果 CR 之后再對(duì)之前的諸多 MR 進(jìn)行修改成本太大；而且一次性太多的 CR 會(huì)打擊團(tuán)隊(duì)成員的積極性。第二種 MR 相對(duì)就輕松的多，可以考慮輪班每天設(shè)置 2-3 人對(duì)當(dāng)天的 MR 進(jìn)行 CR 即可。

2.3 CR 的時(shí)機(jī)

CR 的環(huán)節(jié)應(yīng)該設(shè)立在提測(cè)環(huán)節(jié)之前。因?yàn)?CR 后如果優(yōu)化代碼雖然理論上只是代碼優(yōu)化，但很可能會(huì)對(duì)業(yè)務(wù)邏輯產(chǎn)生影響，如果在提測(cè)時(shí)候，那么可能會(huì)影響到已經(jīng)測(cè)試過(guò)的功能點(diǎn)。
當(dāng)然也要分情況，如果遇到比較緊急的需求或者 bug 修復(fù)，那么也可以先提測(cè)，后續(xù)再做相應(yīng)的 CR。

3. 對(duì)團(tuán)隊(duì)成員要求

前面已經(jīng)提到，要增強(qiáng)團(tuán)隊(duì)成員對(duì) CR 環(huán)節(jié)的認(rèn)同感。作為 CR 環(huán)節(jié)的參與者，還應(yīng)該根據(jù)自己的團(tuán)隊(duì)特點(diǎn)，對(duì)團(tuán)隊(duì)成員做出相應(yīng)要求，可以參考我們團(tuán)隊(duì)。

3.1 Reviewer

1. 指明 review 的級(jí)別。reviewer 再給相應(yīng)的代碼添加評(píng)論時(shí)，建議指明評(píng)論的級(jí)別，可以在評(píng)論前用 [] 作出標(biāo)識(shí)，例如：
• [request]xxxxxxx　　　　　　　此條評(píng)論的代碼必須修改才能予以通過(guò)
• [advise]xxxxxxxx　　　　　　　此條評(píng)論的代碼建議修改，但不修改也可以通過(guò)
• [question]xxxxxx　　　　　　　此條評(píng)論的代碼有疑問(wèn)，需 reviewee 進(jìn)一步解釋
2. 講明該評(píng)論的原因。在對(duì)代碼做出評(píng)論時(shí)，應(yīng)當(dāng)解釋清楚原因，如果自己有現(xiàn)成的更好地解決思路，應(yīng)該把相應(yīng)的解決思路也評(píng)論上，節(jié)省 reviewee 的修改時(shí)間。
3. 平等友善的評(píng)論。評(píng)論者在 review 的過(guò)程中，目的是提升項(xiàng)目代碼質(zhì)量，而不是抨擊別人，質(zhì)疑別人的能力，應(yīng)該保持平等友善的語(yǔ)氣。
4. 享受 Code Review。只有積極的參與 CR，把 CR 作為一種享受，才能將 CR 的價(jià)值最大化的體現(xiàn)。

3.2 Reviewee

1. 注重注釋。對(duì)于復(fù)雜代碼寫明相應(yīng)注釋，在進(jìn)行 commit 時(shí)也應(yīng)簡(jiǎn)明的寫清楚背景，幫助 reviewer 理解，提高 review 的效率。
2. 保持樂(lè)觀的心態(tài)接受別人的 review。團(tuán)隊(duì)成員的 review 不是對(duì)你的批判，而是幫助你的提升，所以要尊重別人的 review，如果 review 你感覺(jué)不正確，可以在下面提出疑問(wèn)，進(jìn)一步解釋。
3. 完成相應(yīng) review 的修改應(yīng)當(dāng)在下面及時(shí)進(jìn)行回復(fù)，保持信息同步。

- END -

版權(quán)聲明

本文來(lái)源：“掘金”微信公眾號(hào)，原文作者“墨鄉(xiāng)客”，鏈接（https://juejin.im/post/6882333635203039239），版權(quán)歸原作者所有，如有侵權(quán)請(qǐng)后臺(tái)聯(lián)系小編刪除。