代码审查

编辑
本词条由“匿名用户” 建档。

通过评审,对软件开发的工作结果进行人工检查。任何工作产品都可以由另一个人审查。审查是一种静态测试方法,属于分析质量保证措施的范畴。 基于IEEE标准IEEE-730,审查是一个或多或少正式计划和结构化的分析和评估过程,在该过程中,项目结果将提交给一组审查人员,由他们评论或批准它们。 审查的审查对象可以不同。主要区分代码审查(源代码)和架构审查(软件架构,尤其是设计文档)。自述文件、安装说明或用户手...

代码审查

编辑

通过评审,对软件开发的工作结果进行人工检查。 任何工作产品都可以由另一个人审查。 审查是一种静态测试方法,属于分析质量保证措施的范畴。

基于 IEEE 标准 IEEE-730,审查是一个或多或少正式计划和结构化的分析和评估过程,在该过程中,项目结果将提交给一组审查人员,由他们评论或批准它们。

审查的审查对象可以不同。 主要区分代码审查(源代码)和架构审查(软件架构,尤其是设计文档)。 自述文件、安装说明或用户手册等技术文档分配给这些区域,还有安装所需的程序或脚本,以及包含信息和说明的文档,供其他具有类似资质的开发人员执行翻译源在稍后时间点成功复制的过程,例如错误修复(纠错)或进一步开发。

在代码审查中,程序部分在开发后或开发期间由一名或多名审查员校对,以发现可能的错误、简化或测试用例。 评估者本身可以是软件开发人员。 对于没有经验的开发人员,经验丰富的程序员的代码审查提供了一个以实践为导向的方式更快地学习的好机会。

评论的好处

编辑

使用评论可以显着减少错误。 根据 Capers Jones 对大约 12,000 个项目的研究,需求审查导致预期错误减少了 20% 到 50%,顶层设计审查减少了 30% 到 60%,详细功能设计审查减少了 30% 到 60% 65%,详细的逻辑设计审查在 35% 到 75% 之间。 这大致对应于系统测试的有效性(占所有错误的 25% 到 65%)。 中尉 Steve McConnel 的设计和代码审查发现了大约 60% 的错误。

种质量流程在这里进行:

  • 程序员自己发现了一个改进的机会。
  • 审阅者提出理解性问题,程序员可以更改代码(例如,通过适当的命名或文档),以便回答这些问题,从而提高可理解性。
  • 审阅者发现改进机会并将其推荐给程序员。

通过审查可以发现的典型弱点包括:

  • 偏离标准,例如 B. 违反命名约定
  • 不符合(甚至不符合)要求的错误
  • 设计错误
  • 维护性不足
  • 接口规范不正确

除了发现的错误之外,代码审查的结果是提高了代码质量。 这反过来又可以防止将来出现错误并提高效率; 健壮性; 可维护性,例如通过降低复杂性。 此外,与仅在测试执行期间发现的错误相比,在审查中发现的错误通常可以更便宜地纠正,因此审查和​​检查可以将软件开发成本降低多达 30%。

审核流程

编辑

典型的审查包括以下主要阶段:

规划

  • 选择相关人员并担任角色
  • 确定前置条件和后置条件

开球

个人准备

  • 注意潜在的错误、问题和评论

回顾会议

  • 讨论和记录结果
  • 针对错误提出建议或做出决定

修订

  • 修复发现的错误,通常由作者修复

后处理(跟进)

  • 评论评论
  • 检查测试结束条件

评论类型

编辑

审查从非常非正式(非结构化)到非常正式(即深度结构化和监管)不等。 进行审查的方式取决于审查的既定目标(例如,发现错误、获得理解或通过讨论达成共识)。

根据 IEEE 1028 标准,有四种评审类型:

技术审查

    • 对关键文件(例如架构设计)进行技术审查以确保符合规范

目的:讨论、决策、评估备选方案、发现错误、解决技术问题

非正式审查

  • 与技术审查的内容相对应,但为了比它节省时间,它作为一个非正式的过程进行。
  • 非正式审查未包含在 IEEE 软件审查标准中。
  • 可以进行结构化日志记录/文档记录。 在实践中,报告通常只以更简单的形式创建,有时甚至完全省略。
  • 这是一种简单的审阅类型,主要通过“同事校对”完成。
  • 在内容方面,可以将以下与实践相关的审核类型分配给此类型(术语因公司文化而异):
    • 桌面测试(程序作者使用简单的测试用例在脑海中运行代码。)
    • 同行评级(同行程序员对程序匿名产生的意见。)
    • 意见程序(作者将工作成果分发给选定的审稿人进行评估。)

演练

  • 在一组平等的员工中以尽可能少的努力讨论场景、测试运行和备选方案
  • 目的:学习、加深理解和发现错误

检查

  • 采用符合 IEEE 1028 的书面程序的最正式的审查技术。
  • 目的:目视检查文档以发现缺陷(例如,不符合开发标准、不符合规范等)。

代码审查

成功因素

编辑

为了成功进行审查,必须满足各种条件:

  • 明确目标的定义
  • 选择合适的人
  • 建设性批评(客观地解决发现的错误并积极接受)
  • 心理方面(特别是确保作者获得积极的体验)
  • 选择适当的审查技术
  • 管理层对审查过程的支持
  • 存在学习和流程改进文化

审稿人要求:

  • 代码一定不是他自己写的。
  • 他必须机智:代码审查可能会让程序员感到不舒服,因为他可能会觉得自己的代码正在受到批评。 如果审阅者不机智,就会增加对源代码审阅的抵制和拒绝。

作为哲学的评论

编辑

在结对编程中不断检查源代码也是极限编程的方法之一。 极限编程 (XP) 中使用的结对编程也称为“开发期间的代码审查”。

公开审查也是开源软件的一个动机。

Github、GitLab 或 Bitbucket 等在线软件存储库允许多个人一起进行代码审查,从而提高程序代码的安全性和质量。 例如,可以指定在可以将此更改与其余代码合并之前,必须有最少数量的地区官员批准更改。

此外,还可以在要审查的代码中标记出静态代码分析工具已经识别出的问题区域,即这些问题也在审查中处理。

内容由匿名用户提供,本内容不代表vibaike.com立场,内容投诉举报请联系vibaike.com客服。如若转载,请注明出处:https://vibaike.com/366070/

(7)
词条目录
  1. 代码审查
  2. 评论的好处
  3. 审核流程
  4. 评论类型
  5. 成功因素
  6. 作为哲学的评论

轻触这里

关闭目录

目录