代码提交及代码评审

举报
ruochen 发表于 2021/07/29 11:20:58 2021/07/29
【摘要】 代码提交及代码评审

代码提交及代码评审

代码提交过程

  • 常见的开发模式有两种:
    • 直接在主干上进行开发发;由于所有人都在主干开发,每一次提交都会直接影响主干代码,所以需要团队成员严格遵守纪律,从而保障团队高效协作
    • 使用分支-主干模式进行开发发,使用分支可以保证主干代码不受损害,团队成员一般遵循如下步骤
      • 创建开发分支,检出最新的成功代码
      • 本地修改代码
      • 在本地进行编译构建,确保本地修改没问题
      • 合入自己的开发分支,并触发分支门禁(静态检查、编译构建等),通过之后进行代码审核再合入,确保代码质量达标
      • 开发进行功能验证
      • 合入到团队主干分支,触发主干门禁构建,门禁构建通过之后,再通过代码评审合入到主干,保障主干代码质量

在这里插入图片描述

Clean Code

  • 代码可信在华为就是用 Clean Code 来衡量
    在这里插入图片描述

Clean Code 的衡量维度

  • 简洁
    • 易于理解并且易于实现,代码少但功能完备,代码的内部质量影响代码的外部质量,简洁是代码内部质量的核心
  • 可靠
    • 软件在给定时间和环境条件下,按设计要求成功运行程序的概率,如果一段代码运行经常容易报错,这种代码达不到发布条件
  • 高效
    • 代码被阅读和被修改的次数,远远多于它被编写的次数。所以要尽可能少地占用系统资源(效率)
  • 可维护性
    • 是指软件被修改的能力,一段代码具备相应功能,但是重构起来很麻烦也是不可取的,所以代码应有很好的可维护性
  • 可测试
    • 是指在一定的时间和成本前提下,对软件进行测试设计和测试执行的能力
  • 可移植
    • 是指为了在原来设计环境之外运行所做的修改能力

如何评估 Clean Code

在这里插入图片描述

  • 专家评审
    • 专家评审包括“每分钟爆粗口的次数”,命名准确,注释精简,函数短小,重复极小,依赖最少,职责单一,隐藏细节,合理抽象,测试相伴等维度

每分钟爆粗口的次数:当看到写的很差的代码,往往会吐槽,甚至爆粗口,越差的代
码爆粗口次数显然也就越多,反之则表示代码质量很好,用每分钟爆粗口次数简单直
白的衡量代码质量,甚至有人将其称为衡量代码质量的唯一标准

  • 工具评估
    • 工具评估是指使用一些代码检查工具,对代码各方面维度包括编译告警,冗余代码,危险函数,重复代码,圈复杂度,pclint告警,CodeDEX告警,编程规范,SAI,QDI=>达标和挑战架构一致等进行检查

Clean Code 可视化指标

指标名称 指标含义 编程指导
圈复杂度 衡量一个函数判定结构的复杂程度,表现为独立路径的条数,即合理的预防错误所需的测试的最少路径条数 减少函数的分支数(if/else,switch/case,for/while),分支逻辑尽量用函数封装
嵌套层数 函数中控制结构嵌套的深度 嵌套层数不要过深(即 {} 的嵌套不能太多)
有效注释比例 函数中有明确含义的注释语句与函数物理行的比值 变量及函数名实现自注释,注释说明 why 而不是 what,注释充分而简洁
有效代码行数 函数用有实际语义的语句个数,可理解为 NBNC(非空非注释)去掉括号等分隔符之后的代码行数 函数体不要过大,逻辑语句不能太多(即 ; 的个数),要注意适当做函数封装
函数参数个数 / 减少函数参数;引入结构体变量
局部变量个数 / 数据关系是由代码的功能引起的,尽量把单一功能的函数进行封装,就可以减少局部变量
非结构化语句的数量 影响函数条理化的语句(eg:异常退出语句、goto 等语句)的数量 尽量不使用

华为 Commiter 工程实践

  • Developer接受到问题或需求,然后创建本地分支进行功能开发,开发完成后进行自验证,验证成功后,向主干分支提交入库申请并且分别选择 Reviewer 和 Committer
  • IT 工具触发门禁检查,如果代码质量符合门禁要求,则由 Reviewer 进行人工代码检视
  • Reviewer 收到代码检视通知后,对代码进行检视并提出代码检视意见
  • Developer 收到检视意见后,完善代码并闭环检视意见,更新代码入库申请
  • Committer 按照入库规范审核,审核通过后进行代码入库
  • 以上任意环节出现问题,都将代码打回,由developer重新再本地进行修改

在保证代码质量的前期下,门禁检查和代码检视可并行执行。同时,Committer 还可对代码检视的策略进行灵活调整

序号 角色名称 关键任务
1 Developer 开发特性需求,修改问题,对合入代码质量承担第一责任
2 Reviewer 对业务逻辑的正确性、代码规范的遵从度、代码架构等方面进行检视,并提出修改意见。若有多名 Reviewer,分工可各有侧重
3 Committer 审核(含代码检视)申请入库的代码质量,对审核的代码质量承担共同责任。担任 Committer 角色的人员应作为 Reviewer 之一

代码入库检查的价值

  • 基于当前可信诉求的提高,代码提交与合入权限应要分离,以避免攻击者冒用员工权限植入恶意代码
  • 同时通过检视和审核的意见对工程师进行辅导,提升团队软件能力
  • 入库审核还能反向驱动前端代码检视提升,促进 Developer 具备编写 Clean Code 的能力
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200