极狐产品研发团队代码审查

1. 你在这里:
2. 极狐 Handbook
3. 极狐研发团队
4. 极狐产品研发团队代码审查

• 总览
• JH MR 的 review 流程
• Upstream MR 的 review 流程
• Reviewer 和 maintainer
  • 如何成为 maintainer
• Review 第一响应时间
• 尽早沟通
• 提升 code review 的速度
• 主要关注点
• 包容性

总览

代码审查（code review）是我们日常开发工作中非常重要的一个环节，每个合并请求（MR）都必须进行 code review。好的 code review 保证了我们在快速迭代的同时，代码具备足够的健壮性和可维护性，这是我们确保产品质量的基石。极狐GitLab 的所有 MR，无论是由极狐GitLab 团队成员还是社区成员编写，都必须经过 code review 流程，以确保代码有效、可理解、可维护和安全。

JH MR 的 review 流程

1. 当一个 JH MR 被创建出来后，请在 MR 中 @ 团队内部的一位同事从代码逻辑的角度去 review 这个 MR（如果你不知道找谁合适，请联系你的 manager）。
2. 如果 MR 中涉及到了数据库相关的代码改动，还需要 @ 毛超(@chaomao) 从数据库的角度进行 review。
3. MR 被上面两步的 reviewer approve 后，还需要相关同事从安全的角度进行 review，会自动进入 Triage Ops 安全审查流程，安全 review 完成后会打上 ~"security-review::approved" 的标记。

Upstream MR 的 review 流程

请先阅读 JiHu Contribution Review Process，了解 GitLab Inc. 关于 JiHu Contribution 的 review 流程。

1. 在创建一个 upstream MR 时，请先把它 标记为 draft 并在 MR 的 description 中 @ 你的 manager，然后进行 peer review，peer review 的流程和 JH MR 的 review 流程保持一致，在 peer review 通过后请在 comment 中留言 LGTM 或者 Looks good 等表示通过。
2. Peer review 完成后，把 MR 标记为 ready 然后让 GitLab Inc. 的同事去做代码逻辑的 review，这里有两种不同的做法：
   • 执行命令 @gitlab-bot ready（如：这个 MR 的做法），这个命令会自动指派一位 reviewer。
   • 如果你非常清楚 GitLab Inc. 的哪位同事比较适合去做 review（比如：他之前就对这个 MR 的背景和上下文比较了解），那你也可以在执行命令 @gitlab-bot ready 的时候直接 @ 他（如：这个 MR 的做法），他就会被直接指派为 reviewer。
   • 对于特别复杂的 MR，可以通过 这个文件 找到 MR 所对应 group 的 EM，然后在 MR 中 @ 这个 EM 让他来帮忙指派合适的 reviewer。
3. 如果这个 MR 中涉及到了数据库相关的代码改动，请 @ reviewer roulette 推荐的 reviewer 来进行数据库相关的 review，如：，并参考文档数据库审查指南。
4. 如果这个 MR 中涉及到了认证、授权相关的代码改动，请 @ Approvers widge 中列出的一位 reviewer 来从这两方面进行 review，如：
5. 当上面三步中任意一步的 reviewer approve MR 后，GitLab Inc. security team 还会被自动通知来从安全的角度进行 review（比如：这个 MR）。关于 security review 的更多细节，详见 此处。

Reviewer 和 maintainer

所有极狐GitLab 的工程师都可以作为 reviewer 对同事和社区贡献者的 MR 进行 code review，但只有 maintainer 才有权接受 MR。

Maintainer 是 code review 方面的专家，非常了解极狐GitLab 的产品特性、相关代码和编码规范，并且有权合并一个或多个极狐GitLab 项目中的 MR。下表列出了当前我们所有的 maintainer：

Area	Maintainers
Backend	Baodong: @icbd on both jihulab.com and gitlab.com Dave: @daveliu on both jihulab.com and gitlab.com Fu: @prajnamas on both jihulab.com and gitlab.com Chao: @chaomao on both jihulab.com and gitlab.com Martin: @mtan-gitlab-cn on jihulab.com and @mtan-gitlab on gitlab.com
Frontend	Jeremy: @jeremywu on jihulab.com and @JeremyWuuuuu on gitlab.com

如何成为 maintainer

快速提升 code review 能力的最佳方式就是尽可能多地参与 MR 的 review，在 MR 中添加你的 review comments，并持续关注这些 comments 的进展直至 MR 被合并或关闭。如果在 code review 的过程中遗漏了一些本应关注的点，请把它们记录下来以确保在后续 review 别的 MR 时不会出现类似的问题。

成为 maintainer 需具备如下两个条件：

1. 持续输出高质量的 code review：你所 review 过的 MR 在经由 maintainer review 时无需再进行较大的代码改动。
2. 持续输出高质量的 MR ：你所写的 MR 在被 reviewer 和 maintainer 进行 review 时无需进行较大的代码改动。

持续做到上述两点后，你可以通过如下方式申请成为 maintainer：

1. 创建一个 MR 把自己加入到上面的 maintainer 表格中。
2. 在这个 MR 中以具体示例的方式阐述你为成为 maintainer 已经做好了哪些准备，比如：
   1. 你 review 过哪些对产品带来显著改动的 MR ，比如：架构级改动、代码重构、开发体验提升等。
   2. 你 review 过哪些提升产品质量的 MR ，如：测试相关、性能相关等。
   3. 你 review 过哪些交付了一个完整功能的 MR 。理想情况下，这些 MR 应该都是通过快速迭代的方式完成的，所以，一个好的 maintainer 需要能够引导他人把一个较大的 MR 合理地拆分成多个较小的 MR。
3. 把这个 MR assign 给你的 manager 并 @ 其他现有的 maintainer。

批准上述 MR 的流程如下：

1. 这个 MR 会在 open 状态下保留五个工作日，在此期间如果超过半数以上的现有 maintainer 批准了这个 MR，且没有任何 blocking concern，那你的 manager 可以合并此 MR，意味着你正式成为了一位新的 maintainer！
2. 如果这个 MR 在五个工作日内没有得到足够的批准，并且也没有任何 blocking concern，那你的 manager 需要在一个新的评论中 @ 现有 maintainer 让他们尽快提出自己的意见或批准这个 MR，并把这个 MR 再多保留五个工作日。
3. 在额外这五个工作日结束后，任何没有发表意见的 maintainer 默认对此 MR 持中立态度，如果此时没有任何 blocking concern，你的 manager 可以直接合并此 MR。
4. 任何非 blocking concern 可以直接作为一个评论提交到这个 MR 中，而对于 blocking concern，maintainer 需要把它单独发给你的 manager，由你的 manager 跟你沟通并在这个 MR 中添加一个评论来简要描述这个 blocking concern。
5. 对于任何 blocking concern，提出它的 maintainer 需要和你的 manager 一起制定一个具体的计划来帮你在今后的开发工作中解决它。
6. 当你的 manager 合并这个 MR 时，需要添加一个评论来对此次批准流程进行一个总结，类似这样。

在批准成为 maintainer 后，你的 manager 需要：

1. 在 #engineering-internal channel 中正式宣布此事。
2. 把你加入到 #engineering-maintainers channel 中。
3. 把你设置为 https://jihulab.com/gitlab-cn/gitlab 的 maintainer。

Review 第一响应时间

在接收到一个 code review 请求后，应该尽早进行响应，和代码作者进行沟通，我们认为从收到 MR 到第一次进行响应的时间，不应该超过两个工作日。

尽早沟通

如果你被分配 review 一个 MR 但却无法在两个工作日内开始，你应该在 MR 中留下评论，告知作者你会延迟响应。如果可能，你还应该告知作者何时可以开始，或者帮助他们找到替代 reviewer。

作为 MR 的作者，如果第一响应时间内没有收到回复，你可以尝试联系 reviewer，或者寻找其他 reviewer。

提升 code review 的速度

在提升 code review 的速度方面有以下建议：

• 给你的 MR 添加详细完整的说明，如果有前端的改动，要包含界面截图或者视频演示。
• 这个 MR 能不能再拆分，拆成多个更小单元的 MR 来 review （可以参考这里）
• 添加多位 reviewer，从不同角度进行 review。
• 代码作者发起一个 review 会议，在会议上更直观的讲解代码对 review 进度会有很大帮助。

主要关注点

成为 reviewer 是一项具有挑战的工作，有时需要在开发迭代和质量之间做出平衡。但我们认为对 MR 质量的追求，是我们不能妥协的地方，我们在这里列出一些常见的衡量 MR 质量的关注点，这些并不是全部，但可以作为参考：

• 用户体验。代码改动是否创造了好的用户体验？
• 可靠性。代码可靠吗？代码是每次都返回相同的输出，还是我们引入了很多不可预测的副作用？
• 依赖性和脆弱性。此 MR 中的代码是否将外部或内部依赖项引入代码仓库？请记住，每次有新的依赖项时，我们都要慎重考虑。
• 可维护性。我们是否能够轻松地对相关代码进行更改（例如，错误修复和需求更改）？是否添加了不必要的代码？
• 可读性。一个全新的贡献者能否理解相关代码并了解发生了什么？
• 测试。我们几乎应该为任何改动添加测试。

每个 reviewer 都有自己的 code review 风格，他们有自己的专业知识可以提供，但总的来说，我们希望共同致力于确保极狐GitLab 的高质量标准和为我们的用户提供更好的服务。

包容性

在极狐GitLab，我们的目标是尽可能地具有包容性，为大家的成长和学习创造空间。 作为 reviewer，鼓励作者提出问题，并无所畏惧地尝试他/她认为正确的事情。虽然我们希望在极狐GitLab 中获得最高质量的代码，但我们还需要留出空间。在完美主义和推动产品进步之间取得一个巧妙的平衡，这是对 reviewer 一个具有挑战的地方。

如果你发现自己正在处理一个不符合质量基准的 MR，我们要尝试帮助作者从中受到启发，学习经验，再次尝试写出另一个更好的 MR。