1. 简介

本文将介绍 Code Review的相关内容，包含为什么要Code Review，以及Code Review主要review哪些部分的内容，之后讲述如何才能形成一套比较好的Code Review规则和流程。后续讲述了Code review中一些可以遵守的比较好的规则，最后讲述了如何才能让Code review流程跑起来。

本文为最近了解code review相关内容的总结，有问题/有建议可以在评论区帮忙指出，感谢！！！

2. 为什么要code review

代码审查（Code Review）是现代软件开发团队中非常重要的一环，因为它可以带来以下几个方面的好处：

1. 提高代码质量: 通过代码审查，开发团队可以及时发现和修复代码中的问题，包括代码中的错误、潜在的安全漏洞、缺陷和性能问题等，从而提高代码的质量。
2. 减少维护成本: 通过及时发现和修复问题，代码审查可以降低后续维护成本，因为修复问题的成本通常比在后期修复更低。
3. 加强知识共享和团队协作: 代码审查可以帮助团队成员了解项目中其他成员的工作，从而促进知识共享和团队协作，提高团队整体的开发能力。
4. 提高编码规范和标准的遵守: 通过代码审查，可以促进团队成员遵守编码规范和标准，统一团队的代码风格和代码质量要求，提高代码可读性和可维护性。
5. 促进开发者的技能提升和成长：代码审查可以帮助开发者了解项目中的技术细节和最佳实践，从而促进开发者的技能提升和成长。

总之，代码审查可以帮助开发团队提高代码质量和开发效率，降低维护成本，提高团队协作和开发者技能，从而在软件开发项目中发挥重要作用。

3.review哪些部分的内容呢

Code Review整个流程中，比较重要的一个节点，是对代码进行Review,然后指出代码中可能存在的问题。具体主要关注哪些代码问题，应该是每个团队，在实践中总结出适合自己的一套规范。这里大概说明一些通用的Code Review可能需要关注的内容。

3.1 代码结构

1. 代码的组织结构：代码应该按照一定的组织结构进行编写，例如按照功能模块进行组织、按照层次结构进行组织等等。在审查代码结构时，应该关注代码的组织结构是否清晰、是否符合设计原则等方面。
2. 模块化和可重用性：代码应该具有一定的模块化和可重用性，以便于代码的复用和维护。在审查代码结构时，应该关注代码是否具有可重用的模块、是否具有良好的接口设计等方面。
3. 代码的层次结构：代码应该按照一定的层次结构进行编写，例如分为界面层、业务逻辑层、数据访问层等等。在审查代码结构时，应该关注代码的层次结构是否清晰、是否具有良好的模块划分等方面。

3.2 代码逻辑

代码逻辑Review主要 包括条件分支、循环结构、异常处理、错误处理等方面的实现是否合理。

1. 条件分支的检查。 判断条件是否覆盖了所有可能的情况，是否有重复的判断条件是否有不必要的嵌套。
2. 循环结构的检查。 检查循环是否能够正常终止，是否存在死循环，是否有更简洁的循环方式。
3. 异常处理的检查。 是否对所有的错误进行正确的处理，是否提供合适的错误提示，是否能够记录错误日志等。

3.3 代码的可读性和可维护性

Review代码时，需要关注代码的可读性和可维护性，包括代码的命名、注释、缩进、代码段的长度、函数和方法的参数和返回值等方面。

1. 命名应该清晰，简洁，准确。代码中的变量、函数、类等命名应该具有清晰、简洁、准确的特点。而不是简单的字母或数字，且应该使用一致的命名方式，避免混淆。
2. 注释应该清晰、准确地描述代码的含义和作用。不应该重复代码，也不应该存在无用的注释。注释应该保持最新状态，以便后续维护。
3. 代码段的长度合适。：通常情况下，代码段的长度应该保持在一个比较合理的范围内，以保证代码的可读性。一些通用的建议是，每个函数或方法的长度应该控制在 100 行以内。
4. 函数和方法的参数和返回值规范。 函数和方法的参数应该尽量少，入参和出参较多的情况下，可以考虑使用DTO来封装。函数和方法的返回值应该尽可能明确，避免使用不必要的返回值或无意义的返回值。
5. 避免使用魔法数字或魔法字符串。

3.4 代码的可靠性

1. 入参合法性检查。 是否对输入参数进行了合法性检查，避免出现意外的输入错误。
2. 单元测试检查。 是否进行了足够的单元测试，并且能够覆盖各种边界情况。

3.5 代码的可测试性

1. 可测试检查。 代码是否容易编写测试用例，测试用例是否易于理解和维护。
2. 单元覆盖率检查。 测试覆盖率是否足够，是否存在测试漏洞或者未考虑到的场景。

4. 制定cr的规则和流程是什么呢

1. 确定团队的目标和需求

2. 确定code review的规则和流程

   • code review的时间安排，确定审查时机，以及时间安排
   • 确定每次审查的代码量
   • 确定审查的内容: 定义一份可用的checklist，确保审查者可以根据标准和指导进行 review。
   • 确定用于进行 code review 的工具和环境
   • 确定审查后需要进行修改的代码如何重新提交，如何跟踪意见的处理过程。

3. 开始实施

4. 收集和分析数据

   • 收集数据

     • 收集问题类型和解决方式的数据，例如代码问题的类型、解决方式、处理时间等

       1. 记录代码问题，如代码可读性等内容
       2. 记录问题的处理时间
       3. 对问题进行分类

     • 收集code review的时间安排/代码量

       1. 收集每次code review的代码量
       2. 收集开始code review的时机
       3. 每次code review耗时，包含开发和reviewer的耗时
       4. 对项目发布是否有影响

   • 数据分析

     • 根据数据记录结果，获取到code review经常出现的问题

       1. 添加代码静态扫描规则，扫描出通用问题，减少code review问题
       2. 进行对应的分享，完成团队内的知识共享

     • 对code review的耗时进行分析，来改进流程

       1. 不同需求类型，每次code review的代码量是否合适
       2. code review开始的时机是否合适
       3. code review是否对项目发布造成影响，在排期过程中，是否增加对code review的考虑
       4. 对reviewer的工作安排是否受到影响，有的话，如何解决

   • 效果分析

     1. 代码质量的提升: 通过比较一段时间下来，发现的问题数量是否减少

5. 规则和流程的优化

5. 可以遵守的比较好的code review的准则

1. 每个提交的代码必须经过代码审查，以确保代码的质量和可维护性。
2. 在代码审查之前，开发人员应该对自己的代码进行一次自审查，确保代码没有明显的错误和问题。
3. 按照确定的规则进行审查：遵循指定的审查标准和流程，以确保一致性和准确性。
4. 代码审查应该专注于发现代码中的问题和缺陷，而不是对开发人员进行评价或指责。
5. 不要强制修改：审查人员应该将自己的建议视为建议而非命令，并与开发人员进行协商。
6. 在代码审查中，开发人员应该积极参与讨论，提出自己的观点和想法，并接受他人的反馈和建议。
7. 代码审查应该在合适的时间进行，以避免影响开发进度和项目交付时间。
8. 代码审查结果应该被记录下来，并及时修复和追踪问题，确保问题得到解决和修复。

6. 如何让code review跑起来

6.1 通过checklist来做code review

通过checkList来做code review似乎是一个比较好的方式，下面是开发者和reviewer的一个checkList的示例。

6.1.1 开发者的checklist

1. 需求评审需要邀请reviewer参加
2. 代码被审查前，自己先review一遍
3. 需要提前和reviewer协调好代码review的时间
4. 每次合并代码前都需要通过代码审查
5. 代码有必要做单元测试的位置，已完成单元测试的覆盖，单元测试已通过

6.1.2 reviewer的checkList

1. 需要review的代码，需要参加需求评审/测试用例评审
2. 需要预先留出code review的时间，排期时确定
3. 代码review根据审查标准执行
   • 每次合并代码是否通过代码审查
   • 代码结构是否符合规范
   • 代码逻辑是否存在问题
   • 代码是否具有一定的可读性
   • 代码单元测试用例是否覆盖充分
4. 代码review需要记录问题类型，方便统计数据

6.2 限制 Code Review 时间

限制单次code review的时间，能够避免待review的代码量过多，如果一次待review的代码量过多，此时整个流程很容易流于形式。因此，这里可以根据不同团队的实际情况，定义好单次code review的耗时，限制在一个时间范围内。

6.3 代码静态扫描规则的建立

对于一些常见的代码review的问题，可以制定代码扫描规则，在code review之前，先执行一次代码扫描，识别出其中比较常见的问题，减少代码review的时间。

这样对于也减轻了reviewer的负担，也利于开发者自行发现问题，自行解决，避免时间的浪费。

6.4 学习和分享

团队中的成员可以定期分享 Code Review 的经验和技巧，以便更好地提高审查的效率和质量。
有这样一个分享，那么code review这个过程可以作为一个输入，能够增加大家code review的参与度。

6.5 反馈和改进

code review的流程，在执行过程中，大概率会发现其中并不合理的地方，或者有待改进的地方，此时应该每隔1个月/2个月，来回顾整个流程，发现其中不合理的地方，让code review更好得进行下去。

同时，在code review过程中，也有收集一些code review的数据，可以对其进行分析，发现其中不合理的地方，针对不合理的地方进行改进。

7. code review的流程建立的实践

7.1 确定团队目标

首先，团队建立code reviwe的目标和需求，为什么要code review,有目标了，后续才能评估code review是否达到了目的。

7.2 时间节点的确定

首先需要确定code review的时间节点的安排。是开发完成后，提测前开始code review还是其他时间节点呢。code review的时间安排是否包含到项目排期中。

reviewer是否得提前知会，在何时知会? 其是否要参加需求评审以及测试用例评审等项目相关需求的评审会? 以及reviewer在code review过程的所耗工时要怎么统计呢，是不是在项目排期时，也需要考虑到code review的耗时，然后耗时大致的排期，是否设定为开发时间的10%,还是其他，是否先执行，后续再根据实际情况调整呢?

7.3 review平台以及review形式的确定

上面code review的时间安排已经确定好了，之后便需要开始code review,这里需要团队内确定code review的工具，是使用开源工具，如reviewBoard,亦或者是直接gitlab平台提交mr的时候顺便review呢,这个也需要确定。

当平台确定好之后，我们需要确定review的形式，是开发和reviewer一起review,reviwer一边看一遍提问，亦或者是reviewer先整体看一遍，然后有疑问再提出，然后开发再当面说明，或者是其他形式，这个也是需要确定的。

7.4 review代码量的确定

之后比较重要的点，便是每次review的代码量的问题,我们可以想象，如果每次需要review的几千行的代码，此时往往review便会流于形式，其实并不会起到太大的作用。这里应该由团队内部协商好code review的形式，是单次少量，多次review; 还是项目开发完成之后，再整体review; 或者是两者的结合,一些项目整体开发完成之后再review,一些项目采取单次少量，多次review的形式，亦或者是其他。

7.5 review内容的确定

接着，就要开始代码review,这里就需要确定review主要review哪些内容，这个示例可以参考第三点所说的，review哪些部分的内容，不过还是需要团队自行确定。不过这里有个前置依赖，团队需要有一套统一的代码规范，如命名规范等。这里假设已经确定review的内容包含代码的可读性，如果没有一套统一的规范，review流程是比较难执行下去的。

7.6 数据收集方式确定

到这里，我们可以算是完成了一次code review的流程，但是一个流程如果只有执行，没有回顾，那是不太合适的，所以对于code review的流程是需要定时回顾的。当进行回顾时，需要有数据来做支撑的，才能识别出整体流程是否存在不合理的地方，那数据从哪里来呢?那只能从每次代码review的过程中获取。

所以，这里也需要定义每次review流程中，需要记录下来一些内容，方便后续回顾，具体记录的内容，可以参考第四点制定cr的规则和流程是什么呢 中第四点的内容，然后数据记录的方式也可以统一一下，比如使用飞书文档或者多维表格，亦或者是其他形式来存储。方便后续回顾使用。

7.7 code review如何更好得执行

当上面的内容都确定好之后，在我看来，一个code review的流程其实就已经完成了，这个时候便可以考虑如何让code review整个流程跑得更顺畅，这里可以参考第六点如何让code review跑起来中的内容，比如使用checkList来减轻心智负担，其次可以建立静态扫描规则集，能够减少code review的工作量等。

7.8 定时回顾

然后再定时回顾整个code review的流程，发现其中不合理的地方，再对其进行改进。

8. 总结

该文档是一篇关于Code Review的输出，介绍了Code Review的规则和流程需要包含的内容，以及具体需要Review的内容。此外，还描述了一些在Review过程中需要遵守的原则，如尊重，建议等，以保持Review的积极性和有效性。
最后，列举了一些方式，如定期进行Review、使用静态代码扫描工具、checklist来进行code review，进行学习和分享，能够让Code Review更好地执行下去。