剛入職，就被各種 Code Review，真的有必要嗎？

點選上方“芋道源碼”，選擇“設為星标”

管她前浪，還是後浪？

能浪的浪，才是好浪！

每天 8:55 更新文章，每天掉億點點頭發...

源碼精品專欄

• 原創 | Java 2020 超神之路，很肝~
• 中文詳細注釋的開源項目
• RPC 架構 Dubbo 源碼解析
• 消息中間件 RocketMQ 源碼解析
• 資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
• 作業排程中間件 Elastic-Job 源碼解析
• 分布式事務中間件 TCC-Transaction 源碼解析
• Eureka 和 Hystrix 源碼解析
• Java 并發源碼

來源：juejin.cn/post/

6882333635203039239

• 1.1 提升團隊代碼品質
• 1.3 保證項目的統一規範

2.1 預留CR的時間

2.3 CR的時機

3.1 Reviewer

衆所周知，Code Review是開發過程中一個非常重要的環節，但是很多公司或者團隊是沒有這一環節的，今天筆者結合自己所在團隊，淺談Code Review的價值及如何實施。

1. Code Review的價值

許多團隊沒有Code Review環節，或者因為追求項目快速上線，認為CR浪費時間；或者團隊成員缺少CR觀念，認為CR的價值并不大。是以想要推動CR在團隊中的實施，最最重要的一點便是增強團隊成員對CR環節的認同感。

Code Review環節，它更加依賴于團隊成員的主觀能動性，隻有團隊成員對其認可，他們才會積極地參入這一環節，CR的價值才能最大化的展現。如果團隊成員不認可CR，即使強制設定了CR流程，也是形同虛設，反而可能阻礙正常開發流程的效率。那麼如何讓團隊成員認可CR環節呢，自然是讓他們意識到CR的價值，然後就會……真香！

1.1 提升團隊代碼品質

随着團隊規模的擴大和項目的疊代更新，團隊之間的資訊透明度會越來越低，項目的可維護性也會越來越差，可能引發如下一系列問題：

1. 已有的utils方法，重複造輪子
2. 代碼過于複雜，缺少必要注釋，後人難以維護
3. 目錄結構五花八門，雜亂不堪

…… 合理的CR環節，可以有效地把控每次送出的代碼品質，不至于讓項目的可維護性随着版本疊代和時間推移變得太差，這也是CR的首要目的。CR環節并不會降低開發效率，就一次代碼送出來說，也許部分人認為CR可能花費了時間，但是有效的CR給後人擴充和維護時所節省的時間是遠超于此的。

1.2 團隊技術交流

Reviewer和Reviewee，在參與CR的過程中，都是可以收獲到許多知識，進行技術交流的。

1. 有利于幫助新人快速成長，團隊有新人加入時（如實習生和校招生），往往需要以為導師帶領一段時間，通過CR環節，可以使導師最直接的了解到新人開發過程中所遇到的問題，作出相應的指導。
2. 通過CR環節，團隊成員可以了解他人的業務，而不局限于自己的所負責的業務範圍。項目發現問題時，可以迅速定位到相關業務的負責人進行修改。同時若有的團隊成員離職後，也可以減少業務一人負責所帶來的後期維護困難。
3. 學習他人的優秀代碼。通過CR環節，可以迅速接觸到團隊成員在項目中解決某些問題的優秀代碼，或者使用的一些你所未接觸過的一些api等。

1.3 保證項目的統一規範

既然要進行CR，首先要對項目的規範制定要求，包括編碼風格規範、目錄結構規範、業務規範等等。一方面，統一的項目規範才能保證項目的代碼品質，提高項目的品質和可維護性；另一方面，在大家熟悉了統一的規範後，能夠提升CR的效率，節省時間。

2. Code Review的實踐

關于Code Review的實踐，要考慮的包括CR所花費的時間、CR的形式、何時進行CR等等。

2.1 預留CR的時間

首先不得不承認，CR環節是要耗費一定時間的，是以在項目排期中，不僅要考慮開發、聯調、提測、改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的環節應該設立在提測環節之前。因為CR後如果優化代碼雖然理論上隻是代碼優化，但很可能會對業務邏輯産生影響，如果在提測時候，那麼可能會影響到已經測試過的功能點。當然也要分情況，如果遇到比較緊急的需求或者bug修複，那麼也可以先提測，後續再做相應的CR。

3. 對團隊成員要求

前面已經提到，要增強團隊成員對CR環節的認同感。作為CR環節的參與者，還應該根據自己的團隊特點，對團隊成員做出相應要求，可以參考我們團隊。

3.1 Reviewer

1. 指明review的級别。reviewer再給相應的代碼添加評論時，建議指明評論的級别，可以在評論前用[]作出辨別，例如：

• [request]xxxxxxx　　　　　　　此條評論的代碼必須修改才能予以通過
• [advise]xxxxxxxx　　　　　　　此條評論的代碼建議修改，但不修改也可以通過
• [question]xxxxxx　　　　　　　此條評論的代碼有疑問，需reviewee進一步解釋

• 講明該評論的原因。在對代碼做出評論時，應當解釋清楚原因，如果自己有現成的更好地解決思路，應該把相應的解決思路也評論上，節省reviewee的修改時間。
• 平等友善的評論。評論者在review的過程中，目的是提升項目代碼品質，而不是抨擊别人，質疑别人的能力，應該保持平等友善的語氣。
• 享受Code Review。隻有積極的參與CR，把CR作為一種享受，才能将CR的價值最大化的展現。

• 3.2 Reviewee

  1. 注重注釋。對于複雜代碼寫明相應注釋，在進行commit時也應簡明的寫清楚背景，幫助reviewer了解，提高review的效率。
  2. 保持樂觀的心态接受别人的review。團隊成員的review不是對你的批判，而是幫助你的提升，是以要尊重别人的review，如果review你感覺不正确，可以在下面提出疑問，進一步解釋。
  3. 完成相應review的修改應當在下面及時進行回複，保持資訊同步。
  歡迎加入我的知識星球，一起探讨架構，交流源碼。加入方式，長按下方二維碼噢：

  

  已在知識星球更新源碼解析如下：

  

  

  

  

  最近更新《芋道 SpringBoot 2.X 入門》系列，已經 20 餘篇，覆寫了 MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等内容。

  提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。

  擷取方式：點“在看”，關注公衆号并回複 666 領取，更多内容陸續奉上。

  兄弟，艿一口，點個贊！????