前言

代码评审，英文名是Code Review，简称CR，它是结对编程相互切磋相互学习的方式。一定频次的CR能够提升咱们的代码质量、促进人才成长。

笔者结合多年深度参与代码评审的经验，梳理代码评审过程与角色，帮你成为代码评审的正规军。

why

代码评审带来的好处不言自明，主要体现在下面几个方面

保证可读性、降低缺陷风险、相互学习、团队融合

how

代码评审活动，从时间维度上可以分为前、中、后三期，从角色维度上可以分为组织者、参与者、记录员、验证人

前期：指发起代码评审前的准备阶段；中期：指代码评审过程；后期指代码评审后的修改和验证环节

组织者：发起代码评审的人；参与者：参与代码评审的人；记录员：评审过程中记录问题的人；验证人：评审后期进行验证复查的人

下面中列出了各个环节中各个角色应该做的事情

前期

【组织者】

什么样的项目需要cr？

p0、p1级应用对应项目中的核心逻辑，核心模块 ​

P0：核心应用级别，如果应用挂了，会造成业务功能大面积影响的应用系统
P1：可降级应用级别，如果应用挂了，有损用户体验，但是不影响业务主要功能，可以减少大面积影响的应用系统
P2：低等级应用级别，如果应用挂了，不需要任何应急处理，不影响主要业务功能，也不造成大面积影响的应用系统
P3：独立应用级别，如果应用挂了，不影响任何业务功能的应用系统

什么时间进行宣讲？

项目提测后的早中期（度过第一波bug比较多的频繁改动期，同时为后续修改留出充足时间）

需要怎么通知？

通过邮件进行会议邀请，会议邀请要素：时间、地点、项目介绍

【参与者】

接到通知

了解项目概况、安排好时间

中期

【组织者】

如何宣讲？

将评审代码优先级进行排序，先讲重点、核心的逻辑

一次会议多久？

一次一个小时，时间太长效果不好（建议小量多次进行）

【参与者】

checkList

代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决

编码规范问题 代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合 ​工具、框架使用不当：Spring、redis、mq等 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好

记录员

将评审过程中发现的问题记录下来，尽量描述清楚问题，同时记录问题提出人、问题责任人

后期

组织者

怎么跟踪后续问题解决？

评审发出会议纪要，列出问题和解决方案

检查人

查收会议纪要

关注问题解决进度和修改方案，复查修改版本是否有误

附录

代码评审记录表模板供参考