Skip to main content

CodeReview规范

敏捷团队是自组织的，拥有跨越团队的技能集。这在一定程度上是通过代码评审实现的。代码评审可以帮助开发人员学习代码库，并帮助他们学习新的技术，从而提高他们的技能。

代码评审的作用​

  • 团队内共享知识
  • 更好的进行工作评估
  • 指导新工程师
  • 节省时间（软件bug扼杀在摇篮里）

整体流程​

code-review-wordflow

创建feature分支，并推送到远端​

分支的命名规则：yourname--what-to-do

create-feature-branch

开发、提交代码​

整个开发过程鼓励提交多次，每个提交遵循 Invest 原则，保证每次提交只做一件事。这样做的好处是代码边界清晰，目标性强，方便评审，比如本文档的制作划分以下2个提交。

  • docs:更新整体流程图
  • docs:更新流程中的步骤描述

开发​

开发内容包括功能实现、本地代码质量扫描、自动化测试实现、执行自查清单。

Commit 本地更改​

拉取dev分支最新代码，并解决冲突（如果有）​

## rebase 方式，修改历史（实践上我们采用 rebase 方式）
git pull origin development --rebase
## merge 方式，保留历史
git pull origin development

Push 更改到远端 feature 分支​

提交PR，代码评审​

提交PR（Pull Request）​

  • 每个 PR 应控制在500行以内（我们的实践中 500 行以下的规则是被严格执行的）

过多的行数说明 PR 的大小划分存在问题，没有遵循 Invest 中的Small 原则，反应了开发者缺少结构化的思维方式。我们很难基于缺少结构化的思维写出的代码写出相应的自动化测试代码，通常称这样的代码是不可被测试的。

另外过多的代码会给评审者带来麻烦，评审者通常是利用碎片时间来评审，没有人愿意一次阅读 2000 行含有多个目的的代码。

当然在实践中我们也发现了例外，一是测试代码不受此约束，二是前端的复杂表单也会超过。

  • 需要填写PR描述，内容包括：
    • PR 说明
    • PR 关联的任务管理系统的链接
    • 测试方法、测试用例、测试结果证据

可以在工程中导入一个 Markdown 模版来保证团队中PR 描述的一致性。

create-pull-request

提出评审意见​

  • 评审者首先阅读 Conversation 选项卡，了解 PR 的内容和开发者的测试方法、测试用例、测试证据 review-read-conversation
  • 评审者然后对目标代码中增加评审意见。对于单个评审通过 add single comment 方式，对于批量评审通过start/submit review 方式 review-read-conversation

评审意见对应​

开发者完成问题对应后，回复 comment。 review-read-conversation

PR 承认通过​

PR 需要满足以下 2 个条件，才被允许合并至目标分支。如果集成了 CI/CD，Pipeline 成功完成也将作为条件之一。

  • 评审者 resolve conversation（工具无法强制，通过团队规则来约束）
  • 评审者 approve PR（此为github 付费版特性，通过 setting - branch 设置，人数可为1～6人）

review-read-conversation

合并至目标分支​

点击 Merge pull request 按钮，完成合并至目标分支。

自动通知​

为了保证交互的实时性，整个代码评审的活动都可以设置自动通知机制。

  • 邮件通知
  • 协同管理工具内通知，如 Lark、Slack

邮件通知​

邮件通知通过 GitHub 通知中心，为两种不同类型的通知选择通知方式。请确保至少第一个 “Email” 是被选中的。接下来，确保在 Emails 画面设置接收用的邮件地址。

mail-notification

设置好后，讲收到来自 github 的自动发送的邮件。 notification-mail

协同管理工具内通知​

Lark​

  • 在 Lark 应用市场 添加 GitHub Assistant。
  • 在 Lark 中找到 GitHub Assistant，用github 账号登陆授权。
  • 添加 Github 助手机器人进入项目群
  • 在 GitHub 配置 webhook

通过 GitHub Assistant 可以实现 Lark 中第一时间获取所有开发动态，让跟踪管理、沟通交流更顺畅。详细设置参照官方说明

notification-kark

常见问题​

  • PR有Review意见怎么对应？
    • 在提交PR的分支上继续修改。
  • 已经merge的PR，有了新的Review意见怎么办？
    • 新建一个分支，进行修改并在提交PR的时候，写明是因为什么进行修改。
  • 移动文件等操作导致行数大于200行怎么办？
    • 特殊问题特殊处理，在PR时写清楚原因
  • 从Dev往feature分支合并怎么办?
    • 使用 git pull origin development --rebase
  • 提交PR前，从Dev rebase的时候，如果发现需要处理的commit比较多怎么办？
    • 如果发现rebase操作比较繁琐，请重新创建一个分支，将代码复制过去，废弃当前分支。
  • This branch is out-of-date with the base branch 怎么处理?
    • Update Branch需要使用命令行
    • git pull origin development --rebase
    • git push -f
  • 有冲突的时候，怎么处理？
    • 因为多个人改同一个文件出现了冲突
    • 把本地修改推到自己的分支
    • git pull origin development --rebase
    • git push -f

命名规范​

Commit​

提交代码的类型:+ 空格 + 具体说明内容

提交代码的类型​
  • feat：新功能点
  • fix：修改（bug）
  • docs：文档类修改
  • style：样式（less，css文件）修改
  • refactor：重构/优化，提高代码质量等
  • chore：含义为苦力，本分支的事情和功能没关系（比如：配置，升级node包…）
  • test：单元测试代码
  • build：就是打个 build，一般就是在发布新版本的时候，你需要更新一下 package.json，然后提交到 git 去自动部署，这个时候就可以用 build，比如 build: v1.2.0
  • factorci：跟 ci 相关的一些修改，大概率是 ci 的配置文件修改
  • perf：就是单纯的性能优化，比如你们如果遇到了性能瓶颈，然后需要提交一些代码去解决这些性能问题，就可以用 perf: enhance performance on xxx page

PR​