阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/6882333635203039239 「梨香」欢迎转载，保留摘要，谢谢！

• 1. Code Review的价值
  • 1.1 提升团队代码质量
  • 1.2 团队技术交流
  • 1.3 保证项目的统一规范
• 2. Code Review的实践
  • 2.1 预留CR的时间
  • 2.2 CR的形式
  • 2.3 CR的时机
• 3. 对团队成员要求
  • 3.1 Reviewer
  • 3.2 Reviewee

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

众所周知，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进一步解释
2. 讲明该评论的原因。在对代码做出评论时，应当解释清楚原因，如果自己有现成的更好地解决思路，应该把相应的解决思路也评论上，节省reviewee的修改时间。
3. 平等友善的评论。评论者在review的过程中，目的是提升项目代码质量，而不是抨击别人，质疑别人的能力，应该保持平等友善的语气。
4. 享受Code Review。只有积极的参与CR，把CR作为一种享受，才能将CR的价值最大化的体现。

3.2 Reviewee

1. 注重注释。对于复杂代码写明相应注释，在进行commit时也应简明的写清楚背景，帮助reviewer理解，提高review的效率。
2. 保持乐观的心态接受别人的review。团队成员的review不是对你的批判，而是帮助你的提升，所以要尊重别人的review，如果review你感觉不正确，可以在下面提出疑问，进一步解释。
3. 完成相应review的修改应当在下面及时进行回复，保持信息同步。