代码审查规范（试用版）

目录

 

1、背景

2、目标

3、流程

4、指定代码审查规范

4.1、命名风格

4.2、常量定义

4.3、代码风格

4.4、注释风格

4.5、控制语句

5、执行代码审查规范

6、开展PR Bash活动

---

1、背景

2019年已成历史，2020年已经悄然到来。2019年，我们的研发团队经历了人员的变动和业务的快速增长。在日常敏捷研发过程、运维过程以及平台升级等过程中，出现了一系列的不可出现的问题，进而产生了一些负面的影响。临近年底，作为项目团队的负责人，对2019年个人的表现以及研发团队的管理工作进行了深度反思，得出了一个根本性的原因就是我们研发团队编写代码的风格随意、代码管控力度不足等，进而埋下了很多的隐患。

为了更好、更高效地支撑公司2020年的业务目标，我制定了《研发团队代码审查流程（试用版）》，对团队各成员编写的代码进行较为严格的审查，尽可能的发现代码中一些低级性的BUG，进而提升产品的质量，具体如下：

2、目标

(1)内建质量，即时发现并移除缺陷，顺畅高质量地交付对用户有效的价值；

(2)持续优化，提升个人及团队的整体编码能力，打造极致体验；

(3)尽可能少踩坑，杜绝踩重复的坑，切实提升平台稳定性，提升协作效率，降低沟通、运维成本；

(4)尽量避免“线上BUG频发，领导发飙，员工抱怨不断，查找BUG困难”情景的发生。

3、流程

如上图可知，团队开展代码审查工作，尝试从以下几方面进行开展：

1、制定代码审查规范，结合项目团队成员日常编程过程中，代码编写不规范（命名风格、常量定义、注释规约、控制语句、异常处理、单元测试、建表规范、SQL语句等等）的严重程度来分阶段的制定审查规范，每次不要改进太多，否则无法真正落地（每个迭代周期可以只关注5~10条左右的改进项）；

2、代码审查规范制定完成后，需组织团队相关人员召开讨论会，针对规范的形式、流程、内容等细节达成共识，明确流程规则，使团队一致理解、承诺，便于后期严格按照《代码审查规范》执行；

3、按照《代码审查规范》执行代码审查，严格把控代码质量，尽最大可能的发现潜在的逻辑问题及BUG，从而降低BUG修改的成本，提升项目的整体性能；

4、开展PR Bash活动，划出一个专门的时间段，所有参与项目的人员，集中全部精力一起来给审核通过的PR找Bug，目的是从各个维度衡量和提升代码质量。该活动开展的频次不宜过高，可每月开展一次，或者每两月开展一次；

5、总结并制定下一步代码审查规范，根据上阶段的执行情况以及项目团队存在的其他不规范的编程习惯，进行逐级改进。 

4、指定代码审查规范

结合近期贵州项目代码审查的执行情况，第一轮代码审查规范主要从命名风格、常量定义、代码风格、注释风格、控制语句等方面进行改进，具体如下：

4.1、命名风格

(1)代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式

(2)类名使用UpperCamelCase风格；方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式

(3)包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式

4.2、常量定义

(1)不允许任何魔法值（即未经预先定义的常量）直接出现在代码中

(2)常量命名全部大写，单词间用下划线隔开，要能表达完整的语意，尽量不要使用缩写的形式

4.3、代码风格

(1)单行字符数限制不超过120个，超出需要换行

(2)单个方法的总行数不超过80行。说明：包括方法签名、结束右大括号、方法内代码、注释、空行、回车及任何不可见字符的总行数不超过80行

(3)随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副 本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化

4.4、注释风格

(1)所有的类都必须添加创建者和创建日期

(2)类、类属性、类方法的注释必须使用Javadoc规范，使用/**内容*/格式，不得使用// xxx 方式

(3)所有的抽象方法（包括接口中的方法）必须要用Javadoc注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能

(4)代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改

4.5、控制语句

(1)超过3层的if-else的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现

(2)循环体内，字符串的连接方式，使用StringBuilder的append方法进行扩展

5、执行代码审查规范

(1)项目团队内容统一IDE环境，安装SonarLint插件（SonarLint是一个代码质量检测插件，可以帮助我们检测出代码中的坏味道）；

(2)团队成员在编写代码时候，需要单独来取分支（切勿直接在master和feature分支上提交代码），将待开发的功能或者待修复的BUG处理完成后，通过SonarLint对编写的代码进行代码质量检测，根据检测结果及整改建议来进行代码重构（团队内容达成共识的《代码审查规范》中约定的改进项是重点需要关注的，不符合代码审查规范的坚决不能提交代码）；

(3)将高质量的代码推送到码云上，然后根据实际情况来发起PR请求，并指派相关的审查人员，审查人员需按照《代码审查规范》对发起人提交的代码进行严格的审核，审核通过后，方可将PR通过 

 

6、开展PR Bash活动

PR Bash，也叫 PR 大扫除，是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。

在发布版本的需求完成之后，尽量专门安排一段时间，组织团队成员一起，集中精力给发布计划的所有功能找问题。假如PR Bash活动落实到位的话，可以发现现有产品的一些逻辑错误，避免上线后可能产生的消极影响，可以提前规避很大的损失。通过这些PR Bash活动，可以把产品验证环节大大地提前了，不仅达到了更好的体验效果，还有效地保障上线质量。

要想组织一场PR Bash活动，可以从以下几个方面入手，具体如下：

（1）时间：可以选择本迭代周期或几个迭代周期所以功能开发完成后，这个活动需要两到三个小时的时间（也可以根据各自团队的实际情况，合理安排），在活动开始之前，要想尽一切办法排除所有的干扰因素；

（2）地点：需要找一个单独的、相对安静的、与外界隔离的空间，鼓励参与者自带笔记本，让大家尽可能集中精力做这一件事。在活动的过程中，可以准备一些水果、零食，尽量让活动保持轻松愉悦的气氛；

（3）人员：除了研发成员和测试人员，PO、运维等项目组 不同角色的人群，都可以参与进来，这样可以从不同的视角来审查代码，尽可能的发现可能的问题；

（4）现场安排：可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键；

（5）活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些 Bug 是必须修的，哪些 Bug 是改了会更好的。另外，千万不要忘记公示结果，明确修复计划，并制定下一阶段的审查规范。