1. 简介
本文将介绍 Code Review的相关内容，包含为什么要Code Review，以及Code Review主要review哪些部分的内容，之后讲述如何才能形成一套比较好的Code Review规则和流程。后续讲述了Code review中一些可以遵守的比较好的规则，最后讲述了如何才能让Code review流程跑起来。
本文为最近了解code review相关内容的总结，有问题/有建议可以在评论区帮忙指出，感谢！！！
2. 为什么要code review
代码审查（Code Review）是现代软件开发团队中非常重要的一环，因为它可以带来以下几个方面的好处：
- 提高代码质量: 通过代码审查，开发团队可以及时发现和修复代码中的问题，包括代码中的错误、潜在的安全漏洞、缺陷和性能问题等，从而提高代码的质量。
- 减少维护成本: 通过及时发现和修复问题，代码审查可以降低后续维护成本，因为修复问题的成本通常比在后期修复更低。
- 加强知识共享和团队协作: 代码审查可以帮助团队成员了解项目中其他成员的工作，从而促进知识共享和团队协作，提高团队整体的开发能力。
- 提高编码规范和标准的遵守: 通过代码审查，可以促进团队成员遵守编码规范和标准，统一团队的代码风格和代码质量要求，提高代码可读性和可维护性。
- 促进开发者的技能提升和成长：代码审查可以帮助开发者了解项目中的技术细节和最佳实践，从而促进开发者的技能提升和成长。
总之，代码审查可以帮助开发团队提高代码质量和开发效率，降低维护成本，提高团队协作和开发者技能，从而在软件开发项目中发挥重要作用。
3.review哪些部分的内容呢
Code Review整个流程中，比较重要的一个节点，是对代码进行Review,然后指出代码中可能存在的问题。具体主要关注哪些代码问题，应该是每个团队，在实践中总结出适合自己的一套规范。这里大概说明一些通用的Code Review可能需要关注的内容。
3.1 代码结构
- 代码的组织结构：代码应该按照一定的组织结构进行编写，例如按照功能模块进行组织、按照层次结构进行组织等等。在审查代码结构时，应该关注代码的组织结构是否清晰、是否符合设计原则等方面。
- 模块化和可重用性：代码应该具有一定的模块化和可重用性，以便于代码的复用和维护。在审查代码结构时，应该关注代码是否具有可重用的模块、是否具有良好的接口设计等方面。
- 代码的层次结构：代码应该按照一定的层次结构进行编写，例如分为界面层、业务逻辑层、数据访问层等等。在审查代码结构时，应该关注代码的层次结构是否清晰、是否具有良好的模块划分等方面。
3.2 代码逻辑
代码逻辑Review主要 包括条件分支、循环结构、异常处理、错误处理等方面的实现是否合理。
- 条件分支的检查。 判断条件是否覆盖了所有可能的情况，是否有重复的判断条件是否有不必要的嵌套。
- 循环结构的检查。 检查循环是否能够正常终止，是否存在死循环，是否有更简洁的循环方式。
- 异常处理的检查。 是否对所有的错误进行正确的处理，是否提供合适的错误提示，是否能够记录错误日志等。
3.3 代码的可读性和可维护性
Review代码时，需要关注代码的可读性和可维护性，包括代码的命名、注释、缩进、代码段的长度、函数和方法的参数和返回值等方面。
- 命名应该清晰，简洁，准确。代码中的变量、函数、类等命名应该具有清晰、简洁、准确的特点。而不是简单的字母或数字，且应该使用一致的命名方式，避免混淆。
- 注释应该清晰、准确地描述代码的含义和作用。不应该重复代码，也不应该存在无用的注释。注释应该保持最新状态，以便后续维护。
- 代码段的长度合适。：通常情况下，代码段的长度应该保持在一个比较合理的范围内，以保证代码的可读性。一些通用的建议是，每个函数或方法的长度应该控制在 100 行以内。
- 函数和方法的参数和返回值规范。 函数和方法的参数应该尽量少，入参和出参较多的情况下，可以考虑使用DTO来封装。函数和方法的返回值应该尽可能明确，避免使用不必要的返回值或无意义的返回值。
- 避免使用魔法数字或魔法字符串。
3.4 代码的可靠性
- 入参合法性检查。 是否对输入参数进行了合法性检查，避免出现意外的输入错误。
- 单元测试检查。 是否进行了足够的单元测试，并且能够覆盖各种边界情况。
3.5 代码的可测试性
- 可测试检查。 代码是否容易编写测试用例，测试用例是否易于理解和维护。
- 单元覆盖率检查。 测试覆盖率是否足够，是否存在测试漏洞或者未考虑到的场景。
4. 制定cr的规则和流程是什么呢
-
确定团队的目标和需求
-
确定code review的规则和流程
- code review的时间安排，确定审查时机，以及时间安排
- 确定每次审查的代码量
- 确定审查的内容: 定义一份可用的checklist，确保审查者可以根据标准和指导进行 review。
- 确定用于进行 code review 的工具和环境
- 确定审查后需要进行修改的代码如何重新提交，如何跟踪意见的处理过程。
-
开始实施
-
收集和分析数据
-
收集数据
-
收集问题类型和解决方式的数据，例如代码问题的类型、解决方式、处理时间等
- 记录代码问题，如代码可读性等内容
- 记录问题的处理时间
- 对问题进行分类
-
收集code review的时间安排/代码量
- 收集每次code review的代码量
- 收集开始code review的时机
- 每次code review耗时，包含开发和reviewer的耗时
- 对项目发布是否有影响
-
-
数据分析
-
根据数据记录结果，获取到code review经常出现的问题
- 添加代码静态扫描规则，扫描出通用问题，减少code review问题
- 进行对应的分享，完成团队内的知识共享
-
对code review的耗时进行分析，来改进流程
- 不同需求类型，每次code review的代码量是否合适
- code review开始的时机是否合适
- code review是否对项目发布造成影响，在排期过程中，是否增加对code review的考虑
- 对reviewer的工作安排是否受到影响，有的话，如何解决
-
-
效果分析
- 代码质量的提升: 通过比较一段时间下来，发现的问题数量是否减少
-
-
规则和流程的优化
5. 可以遵守的比较好的code review的准则
- 每个提交的代码必须经过代码审查，以确保代码的质量和可维护性。
- 在代码审查之前，开发人员应该对自己的代码进行一次自审查，确保代码没有明显的错误和问题。
- 按照确定的规则进行审查：遵循指定的审查标准和流程，以确保一致性和准确性。
- 代码审查应该专注于发现代码中的问题和缺陷，而不是对开发人员进行评价或指责。
- 不要强制修改：审查人员应该将自己的建议视为建议而非命令，并与开发人员进行协商。
- 在代码审查中，开发人员应该积极参与讨论，提出自己的观点和想法，并接受他人的反馈和建议。
- 代码审查应该在合适的时间进行，以避免影响开发进度和项目交付时间。
- 代码审查结果应该被记录下来，并及时修复和追踪问题，确保问题得到解决和修复。
6. 如何让code review跑起来
6.1 通过checklist来做code review
通过checkList来做code review似乎是一个比较好的方式，下面是开发者和reviewer的一个checkList的示例。
6.1.1 开发者的checklist
- 需求评审需要邀请reviewer参加
- 代码被审查前，自己先review一遍
- 需要提前和reviewer协调好代码review的时间
- 每次合并代码前都需要通过代码审查
- 代码有必要做单元测试的位置，已完成单元测试的覆盖，单元测试已通过
6.1.2 reviewer的checkList
- 需要review的代码，需要参加需求评审/测试用例评审
- 需要预先留出code review的时间，排期时确定
- 代码review根据审查标准执行
- 每次合并代码是否通过代码审查
- 代码结构是否符合规范
- 代码逻辑是否存在问题
- 代码是否具有一定的可读性
- 代码单元测试用例是否覆盖充分
- 代码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更好地执行下去。