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