为什么要code review

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更好地执行下去。

热门相关:地球第一剑   第一神算:纨绔大小姐   寂静王冠   网游之逆天飞扬   寂静王冠