开发部门，代码 Code Review 实践方案

绝地灬酷狼 2023-07-25 16:27 22阅读 0赞

Code Review（代码审查）是软件开发中的最佳实践之一，可以有效提高整体代码质量，及时发现代码中可能存在的问题。包括像Google、微软这些公司，Code Review都是基本要求，代码合并之前必须要有人审查通过才行。

## Code Review 好处 ##

团队知识共享的角度

一个开发团队中，水平有高有低，每个人侧重的领域也有不同。怎么让高水平的帮助新人成长？怎么让大家都对自己侧重领域之外的知识保持了解？怎么能有人离职后其他人能快速接手？这些都是团队管理者关心的问题。

而代码审查，就是一个很好的知识共享的方式。通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长；通过代码审查，前端也可以去学习后端的代码，做功能模块A的可以去了解功能模块B的。

可能有些高手觉得给新手代码审查浪费时间，自己也没收获。其实不然，新人成长了，就可以更多的帮高手分担繁重的任务；代码审查中花时间，就少一些帮新人填坑擦屁股的时间；良好的沟通能力、发现问题的能力、帮助其他人成长，都是技术转管理或技术上更上一层楼必不可少的能力，而通过代码审查可以有效的去练习这些方面的能力。

代码质量的角度

现实中的项目总是人手缺进度紧，所以被压缩的往往就是自动化测试和代码审查，结果影响代码质量，欠下技术债务，最后还是要加倍偿还。

也有人寄希望于开发后的人工测试，然而对于代码质量来说，很多问题通过测试是测试不出来的，只能通过代码审查。比如说代码的可读性可维护性，比如代码的结构，比如一些特定条件才触发的死循环、逻辑算法错误，还有一些安全上的漏洞也更容易通过代码审查发现和预防。

也有人觉得自己水平高就不需要代码审查了。对于高手来说，让别人审查自己的代码，可以让其他人学习到好的实践；在让其他人审查的同时，在给别人说明自己代码的时候，也等于自己对自己的代码进行了一次审查。这其实就跟我们上学时做数学题一样，真正能拿高分的往往是那些做完后还会认真检查的。

团队规范的角度

每个团队都有自己的代码规范，有自己的基于架构设计的开发规范，然而时间一长，就会发现代码中出现很多不遵守代码规范的情况，有很多绕过架构设计的代码。比如难以理解和不规范的命名，比如三层架构里面UI层绕过业务逻辑层直接调用数据访问层代码。

如果这些违反规范的代码被纠正的晚了，后面再要修改就成本很高了，而且团队的规范也会慢慢的形同虚设。

通过代码审查，就可以及时的去发现和纠正这些问题，保证团队规范的执行。

## PR 人员交叉审核 ##

<table> 
 <thead> 
  <tr> 
   <th>提交人</th> 
   <th>审查人</th> 
   <th>Merge人</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开发A</td> 
   <td>开发B</td> 
   <td>团队lead</td> 
  </tr> 
  <tr> 
   <td>开发B</td> 
   <td>开发C</td> 
   <td>团队lead</td> 
  </tr> 
  <tr> 
   <td>开发C</td> 
   <td>开发D</td> 
   <td>团队lead</td> 
  </tr> 
  <tr> 
   <td>开发D</td> 
   <td>开发A</td> 
   <td>团队lead</td> 
  </tr> 
 </tbody> 
</table>

## 注意事项 ##

先设计再编码

有些人发现自己的代码提交PR（Pull Request）后，会收到一堆的Code Review意见，必须要做大量的改动。这多半是因为在开始做之前，没有做好设计，做出来后才发现问题很多。

代码在提交CODE REVIEW之前，要自己先 REVIEW 和测试一遍

做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至自己都没有测试过，就等着别人Code Review和测试帮助发现问题，这种依赖心理无论是对自己还是对团队都是很不负责任的。

遇到紧急情况，来不及代码审查怎么办？

虽然原则上，必须要Code Review才能合并，但有时候确实会存在一些紧急情况，比如说线上故障补丁，而又没有其他人在线，那么这种情况下，需要在Jira中，创建一个issue，用来后续跟踪，确保后续补上Code Review，并对Code Review结果有后续的代码更新。

### Pull Request 的说明 ###

*  任务完成才能提交PR。
 *  PR应该在一个工作日内被合并或者被拒绝。 PR在有严重问题（包括但不限于架构问题、安全问题、设计问题），太多问题，或者任务无效的情况下会被拒绝。
 *  严禁一个PR里面有多个任务，除非它们是紧密关联的。
 *  PR提交之后只允许针对Review发现问题再次提交代码，除非有充足的理由，严禁在同一个PR中再次提交其它任务的代码。

提交PR时候有一个描述框，内容会自动根据Commit的message合并而成。 切记，如果一次提交的内容包含很多Commit，请不要使用自动生成的描述。 请用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述：

**你改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。**

**特别需要留意，如果对基础、公共的组件进行了改动，一定要另起一行特别说明。**

审核人员邀请原则：

参见: PR 人员交叉审核列表

## 规范和制度 ##

### 审查规则 ###

不能为了进度牺牲质量，无论进度有多么紧迫，Code Review的过程都一定会做。

所有的问题一定会被提出，只是会根据进度的紧迫程度，以及问题的大小，改动成本，决定问题是现在解决，还是加一个TODO，并记录在缺陷跟踪管理系统内，以防日后遗忘。

多数情况下，我们都会要求立即解决，哪怕因此造成了发布的推迟。

我们深知，其实多数情况下，现在不解决，日后不知道猴年马月才能解决。

代码规范