DevOps系列之 —— DevOps概览(一)软件产业和交付模式发展趋势
DevOps系列之 —— DevOps概览(二)新型软件技术及交付模式
DevOps系列之 —— DevOps概览(三)DevCloud HE2E DevOps 框架及其主要服务
DevOps系列之 —— 持续规划与设计(一)敏捷项目管理理念与方法实践
DevOps系列之 —— 持续规划与设计(二)规划与设计
DevOps系列之 —— 持续规划与设计(三)敏捷项目管理的方法【Kanban 与 Scrum】
DevOps系列之 —— 持续规划与设计(四)敏捷需求管理【用户故事 & 敏捷估算】
DevOps系列之 —— 持续规划与设计(五)团队与协作
DevOps系列之 —— 持续规划与设计(六)华为敏捷项目管理企业实践
DevOps系列之 —— 持续开发与集成(一)持续集成理念、方法及实践
DevOps系列之 —— 持续开发与集成(二)代码托管与分支策略(Git Flow、GitHub Flow & GitLab Flow)
DevOps系列之 —— 持续开发与集成(三)Git 基本概念及主要操作
 
DevOps 系列文章,持续更新中 ~~~

代码提交及代码评审

1. 代码提交过程

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

在这里插入图片描述

2. 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 等语句)的数量尽量不使用

2. 华为 Commiter 工程实践

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

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

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

代码入库检查的价值

  • 基于当前可信诉求的提高,代码提交与合入权限应要分离,以避免攻击者冒用员工权限植入恶意代码
  • 同时通过检视和审核的意见对工程师进行辅导,提升团队软件能力
  • 入库审核还能反向驱动前端代码检视提升,促进 Developer 具备编写 Clean Code 的能力

最后,欢迎大家关注我的个人微信公众号 『小小猿若尘』,获取更多IT技术、干货知识、热点资讯。同时,我在公众号中分享了精心整理的一些视频资料(包括 Python全栈教程、AI教程、前端、数据库等),大家回复相应关键词即可获取网盘视频链接,感谢大家的关注😊

 在这里插入图片描述

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐