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 还可对代码检视的策略进行灵活调整

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

代码入库检查的价值

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

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