华为云DevOps系列之 —— 持续开发与集成(四)代码提交及代码评审
【摘要】 华为云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 还可对代码检视的策略进行灵活调整
序号 | 角色名称 | 关键任务 |
---|---|---|
1 | Developer | 开发特性需求,修改问题,对合入代码质量承担第一责任 |
2 | Reviewer | 对业务逻辑的正确性、代码规范的遵从度、代码架构等方面进行检视,并提出修改意见。若有多名 Reviewer,分工可各有侧重 |
3 | Committer | 审核(含代码检视)申请入库的代码质量,对审核的代码质量承担共同责任。担任 Committer 角色的人员应作为 Reviewer 之一 |
代码入库检查的价值
- 基于当前可信诉求的提高,代码提交与合入权限应要分离,以避免攻击者冒用员工权限植入恶意代码
- 同时通过检视和审核的意见对工程师进行辅导,提升团队软件能力
- 入库审核还能反向驱动前端代码检视提升,促进 Developer 具备编写 Clean Code 的能力
最后,欢迎大家关注我的个人微信公众号 『小小猿若尘』,获取更多IT技术、干货知识、热点资讯。同时,我在公众号中分享了精心整理的一些视频资料(包括 Python全栈教程、AI教程、前端、数据库等),大家回复相应关键词即可获取网盘视频链接,感谢大家的关注😊
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)