代码审查那些事

发布时间:2024年01月03日

代码审查(code review)是指对源代码进行系统化地审查,是软件开发中的最佳实践之一,代码合并之前必须审查通过才行,可及时发现隐藏问题,提高代码质量。

1 为什么要代码审查

代码审查环节,或者流于形式,或者根本没有,软件质量只依赖事后的测试;认真执行是有诸多优势的。

  1. 统一编码规范
    审查代码风格,统一编码规范,有助于代码的可读性,也方便接盘者快速上手。

  2. 提前发现缺陷
    代码审查最直接的优点是发现软件逻辑问题,性能等等潜在风险,提前发现缺陷可以有效节省人力和时间。

  3. 提高代码质量
    代码审查与优化修复,确保代码在健壮性、设计合理性、代码结构等方面持续提升整体质量。

  4. 知识分享
    每一次的代码审查都是一次知识的分享,磨合一定时间后,软件设计融合集体的智慧,团队内相互审查,也是互相学习的一种途径。

  5. 团队共识
    经过讨论与交流逐步达成的团队共识,特别是对架构理解和设计原则的认知,在共识的基础上团队也会更有凝聚力,软件设计方式与会趋于一致,特别是在较多新人加入时尤为重要。

2 代码审查原则

如果变更可提升整体代码质量,就可以让它通过,即使还不完美,这是代码评审准则的最高原则。没有完美的代码,只有更好的代码。评审者不应强求代码提交者在每个细节都写得很完美,应该考量修复时间与修改重要性之间的平衡。

以客观的技术数据为准,而非个人偏好。在代码排版样式上,遵从编码规范,所有代码保持风格一致,但如果新奇代码在编码规范未提及,那就接受作者的样式。同时有多种可行方案时,如果作者能证明这些方案基本差不多,那就接受作者的选择;否则,应以软件设计原则为准,而不应由评审者的个人喜好来决定。

如果没有参考规则,那么评审者应该保证新代码与当前软件库风格一致,至少不会恶化软件的质量,一旦恶化就会带来破窗效应,导致软件质量逐渐下降。

代码审核者应该看什么

命名:变量、函数等命名是否清晰易懂?
注释:核心代码的注释是否都一目了然?
代码排版:所有的代码是否都遵循编码规范?
设计:代码是否设计良好?是否适合当前系统?有没兼容旧版或预留扩展接口?
功能:代码实现的行为与需求是否相符?
复杂性:代码可以更简单吗?如果由其他开发者接手,能否很快理解吗?
文档:开发者是否同时更新了相关文档?

推行代码审查机制,开发流程上专门有这个环节,代码必须审核通过才可以提交。审核结果或记录公开透明,团队内互相审查其他人的代码,甚至明确考评和代码审查表现相关,这样就能落实代码审查制度。

3 怎么做代码审查

3.1 作为代码提交者

发起时机:软件变更发布前提交代码审查申请。
代码行数:提交代码行数最好在500-1000行以下(非有效代码除外),一个高质高效的代码审查最好控制在一个小时以内。

3.2 作为代码评审者

主要从代码逻辑和质量两方面来评审。

代码逻辑

功能完整:代码实现是否满足需求,有没理解偏差。
逻辑设计:是否符合软件框架,功能细节处理是否考虑边界条件和并发控制。
数据安全:是否存在数据安全隐患,参数篡改或丢失。
性能隐患:是否存在损害性能的隐患,如死循环等。
测试用例:单元测试用例的验证逻辑是否有效,测试用例的代码行覆盖率和分支覆盖率。

代码质量

编码规范:命名、注释、架构分层、软件排版等是否符合编码规范。
可读性:是否逻辑清晰、易理解,避免使用奇淫巧技。
简洁性:是否有重复可简化的复杂逻辑,代码复杂度是否过高。
可维护性:是否分层清晰、模块化合理、高内聚低耦合、遵从基本设计原则。
可扩展性:是否仅满足本次需求,是否有必要的扩展设计。
可测试性:代码是否方便写单元测试及分支覆盖,是否便于自动化测试

3.3 评审注意事项

沟通是至关重要的,团队要始终保持沟通,并在整个过程中保持透明度,代码审查提供清晰的反馈修复建议。同时,要记住反馈应该集中在批评代码本身,而不是代码的作者。尽快完成评审,避免过度追求完美,抓住重点,水至清则无鱼。

4 代码审查避免流于形式

代码审查失去意义,主要是审核与否不影响流程,或者时间紧迫必须保项目进度,或者审核结果修改建议无法执行。一旦认为审查是可有可无,后续就越发流于形式。

时间与进度的矛盾

项目压力大时间紧,以致草草分析不做设计,直接编码不做重构,前期快了最后总要有谁来背锅。

每次代码审查的建议都是一次技术交流,但是审查后,发现问题太多,或者改动太大,影响项目计划,理论上要求编码前设计评审方案,实际工作可能是发布前审查,为了项目进度只能认可既定事实。

或者代码审查的力度不够,只能提出一些浅表的问题,建议无非是一些格式、注释、命名之类不痛不痒的问题,草草了事,这个现象其实更为普遍。

评审者不了解业务和代码

代码提交人需编写清晰的修改描述,必要的情况下评审者应熟悉需求,否则,脱离功能实现无法发现真正的逻辑问题。

反馈建议未修改

这一点极为重要,需要对修改后的代码再次审查,确保理解一致,问题建议有接受执行。

代码审查耗费人力

代码审查可能很耗时,特别是处理大型代码库或复杂变更时,评审人员需要花费时间和精力仔细审查代码,这可能会影响整体的开发速度和项目进度。代码审查需要多个团队成员的参与,包括作者和评审人员。这可能对团队资源产生负担,特别是在人员有限的组织中。

5 小节

程序员的智慧结晶都尽在代码之中,而代码审查是打磨它更加的纯洁无瑕、精致完美,这也值得大家一起持续精进,即使实际存在诸多阻碍。

在这里插入图片描述

文章来源:https://blog.csdn.net/chengjunchengjun/article/details/135337278
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。