Code Review 環(huán)節(jié)實施秘訣！
眾所周知，Code Review 是開發(fā)過程中一個非常重要的環(huán)節(jié)，但是很多公司或者團隊是沒有這一環(huán)節(jié)的，今天筆者結(jié)合自己所在團隊，淺談 Code Review 的價值及如何實施。
1. Code Review 的價值
許多團隊沒有 Code Review 環(huán)節(jié)，或者因為追求項目快速上線，認為 CR 浪費時間；或者團隊成員缺少 CR 觀念，認為 CR 的價值并不大。所以想要推動 CR 在團隊中的實施，最最重要的一點便是增強團隊成員對 CR 環(huán)節(jié)的認同感。
Code Review 環(huán)節(jié)，它更加依賴于團隊成員的主觀能動性，只有團隊成員對其認可，他們才會積極地參入這一環(huán)節(jié)，CR 的價值才能最大化的體現(xiàn)。如果團隊成員不認可 CR，即使強制設(shè)置了 CR 流程，也是形同虛設(shè)，反而可能阻礙正常開發(fā)流程的效率。那么如何讓團隊成員認可 CR 環(huán)節(jié)呢，自然是讓他們意識到 CR 的價值，然后就會…… 真香！
1.1 提升團隊代碼質(zhì)量
隨著團隊規(guī)模的擴大和項目的迭代升級，團隊之間的信息透明度會越來越低，項目的可維護性也會越來越差，可能引發(fā)如下一系列問題：
已有的 utils 方法，重復(fù)造輪子 代碼過于復(fù)雜，缺少必要注釋，后人難以維護 目錄結(jié)構(gòu)五花八門，雜亂不堪
……
合理的 CR 環(huán)節(jié)，可以有效地把控每次提交的代碼質(zhì)量，不至于讓項目的可維護性隨著版本迭代和時間推移變得太差，這也是 CR 的首要目的。CR 環(huán)節(jié)并不會降低開發(fā)效率，就一次代碼提交來說，也許部分人認為 CR 可能花費了時間，但是有效的 CR 給后人擴展和維護時所節(jié)省的時間是遠超于此的。
1.2 團隊技術(shù)交流
Reviewer 和 Reviewee，在參與 CR 的過程中，都是可以收獲到許多知識，進行技術(shù)交流的。
有利于幫助新人快速成長，團隊有新人加入時（如實習(xí)生和校招生），往往需要以為導(dǎo)師帶領(lǐng)一段時間，通過 CR 環(huán)節(jié)，可以使導(dǎo)師最直接的了解到新人開發(fā)過程中所遇到的問題，作出相應(yīng)的指導(dǎo)。 通過 CR 環(huán)節(jié)，團隊成員可以了解他人的業(yè)務(wù)，而不局限于自己的所負責(zé)的業(yè)務(wù)范圍。項目發(fā)現(xiàn)問題時，可以迅速定位到相關(guān)業(yè)務(wù)的負責(zé)人進行修改。同時若有的團隊成員離職后，也可以減少業(yè)務(wù)一人負責(zé)所帶來的后期維護困難。 學(xué)習(xí)他人的優(yōu)秀代碼。通過 CR 環(huán)節(jié)，可以迅速接觸到團隊成員在項目中解決某些問題的優(yōu)秀代碼，或者使用的一些你所未接觸過的一些 api 等。
1.3 保證項目的統(tǒng)一規(guī)范
既然要進行 CR，首先要對項目的規(guī)范制定要求，包括編碼風(fēng)格規(guī)范、目錄結(jié)構(gòu)規(guī)范、業(yè)務(wù)規(guī)范等等。一方面，統(tǒng)一的項目規(guī)范才能保證項目的代碼質(zhì)量，提高項目的質(zhì)量和可維護性；另一方面，在大家熟悉了統(tǒng)一的規(guī)范后，能夠提升 CR 的效率，節(jié)省時間。
2. Code Review 的實踐
關(guān)于 Code Review 的實踐，要考慮的包括 CR 所花費的時間、CR 的形式、何時進行 CR 等等。
2.1 預(yù)留 CR 的時間
首先不得不承認，CR 環(huán)節(jié)是要耗費一定時間的，所以在項目排期中，不僅要考慮開發(fā)、聯(lián)調(diào)、提測、改 bug 等時間，還要預(yù)留出 CR 的時間。包括擔(dān)任 Reviewer 和 Reviewee 角色的時間都要考慮。
另外如果遇到的需求比較復(fù)雜，為了避免因為 CR 過程導(dǎo)致代碼需要大量修改，最好提前和團隊成員溝通好需求的設(shè)計和結(jié)果思路。
2.2 CR 的形式
我所見過的 CR 大多有兩種形式。一種是設(shè)立一個特定時間，例如每周或者每半月等等，團隊成員一起對之前的 Merge Request 進行 CR；另一種是對每次的 Merge Request 都進行 CR。
我個人更偏向于后者。第一種定期 CR，Merge Request 的數(shù)量太多，不太可能對所有的 MR 進行 CR，如果 CR 之后再對之前的諸多 MR 進行修改成本太大；而且一次性太多的 CR 會打擊團隊成員的積極性。第二種 MR 相對就輕松的多，可以考慮輪班每天設(shè)置 2-3 人對當天的 MR 進行 CR 即可。
2.3 CR 的時機
CR 的環(huán)節(jié)應(yīng)該設(shè)立在提測環(huán)節(jié)之前。因為 CR 后如果優(yōu)化代碼雖然理論上只是代碼優(yōu)化，但很可能會對業(yè)務(wù)邏輯產(chǎn)生影響，如果在提測時候，那么可能會影響到已經(jīng)測試過的功能點。
當然也要分情況，如果遇到比較緊急的需求或者 bug 修復(fù)，那么也可以先提測，后續(xù)再做相應(yīng)的 CR。
3. 對團隊成員要求
前面已經(jīng)提到，要增強團隊成員對 CR 環(huán)節(jié)的認同感。作為 CR 環(huán)節(jié)的參與者，還應(yīng)該根據(jù)自己的團隊特點，對團隊成員做出相應(yīng)要求，可以參考我們團隊。
3.1 Reviewer
指明 review 的級別。reviewer 再給相應(yīng)的代碼添加評論時，建議指明評論的級別，可以在評論前用 [] 作出標識，例如： [request]xxxxxxx 此條評論的代碼必須修改才能予以通過 [advise]xxxxxxxx 此條評論的代碼建議修改，但不修改也可以通過 [question]xxxxxx 此條評論的代碼有疑問，需 reviewee 進一步解釋 講明該評論的原因。在對代碼做出評論時，應(yīng)當解釋清楚原因，如果自己有現(xiàn)成的更好地解決思路，應(yīng)該把相應(yīng)的解決思路也評論上，節(jié)省 reviewee 的修改時間。 平等友善的評論。評論者在 review 的過程中，目的是提升項目代碼質(zhì)量，而不是抨擊別人，質(zhì)疑別人的能力，應(yīng)該保持平等友善的語氣。 享受 Code Review。只有積極的參與 CR，把 CR 作為一種享受，才能將 CR 的價值最大化的體現(xiàn)。
3.2 Reviewee
注重注釋。對于復(fù)雜代碼寫明相應(yīng)注釋，在進行 commit 時也應(yīng)簡明的寫清楚背景，幫助 reviewer 理解，提高 review 的效率。 保持樂觀的心態(tài)接受別人的 review。團隊成員的 review 不是對你的批判，而是幫助你的提升，所以要尊重別人的 review，如果 review 你感覺不正確，可以在下面提出疑問，進一步解釋。 完成相應(yīng) review 的修改應(yīng)當在下面及時進行回復(fù)，保持信息同步。
- END -
版權(quán)聲明
本文來源：“掘金”微信公眾號，原文作者“墨鄉(xiāng)客”，鏈接（https://juejin.im/post/6882333635203039239），版權(quán)歸原作者所有，如有侵權(quán)請后臺聯(lián)系小編刪除。