代码提交及代码评审

代码提交过程

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

Clean Code

• 代码可信在华为就是用 Clean Code 来衡量
  

Clean Code 的衡量维度

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

如何评估 Clean Code

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

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

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

Clean Code 可视化指标

华为 Commiter 工程实践

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

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

代码入库检查的价值

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