中级开发的经验之谈-代码review流程规范

前提

1、项目已接入公司代码规范，CR 过程中不纠结代码风格，借助pre-commit 关联 lint，避免代码中出现的debugger、console等...
2、接入 husky，规范commit message

• feat：新特性

• fix：修复bug

• chore：优化，如项目结构，依赖安装更新等

• docs：文档变更

• style：样式相关修改

• refactor：重构

一、角色职能

author：需求开发者

1. 对复杂业务写明相应注释，MR 根据MR模版填写基础信息，便于 reviewer 理解。

2. 对于 reviewer 提出的comment，及时响应，完成 comment 修改后及时反馈，commit 提交信息备注，如 review：xxx，保证复检效率。

3. 小批量、多批次提交，每次提交的 review 的代码量要少，commit 写明具体提交背景。

reviewe：cr 参与者，一般有项目负责人或项目参与者组成

1. 说明 comment 等级，reviewer 对相应的代码提出评价时，需要指明相应等级，如

   • [ fix ]：xxxxx；此处需强制修改，提供修改建议。

   • [ advise ]：xxxxx；此处主观上建议修改，不强制，可提供修改建议

   • [ question ]：xxxxx；此处存在疑虑，需要 author 作出解释

2. 在不影响自我工作的前提下，尽快响应，拆分 review 粒度，使快速响应成为可能。Google 的中位数是 4 小时，最大不要超过 1 天。

二、CR 标准

1. 代码注释（复杂 特殊业务逻辑 文档等）

2. 代码可读性（过多嵌套、冗余、变量命名，功能独立等）

3. 代码扩展性（模块拆分 / 设计合理）

4. 遵守 review 范围，原则上只针对此次改动范围进行 review

三、CR 流程

1. self-review

• MR 基础信息是否填写完整

• Owner 确认已完成充分自测

2. CR

1. Owner 启动开发时发起 CR，需求任务关联 reviewer，MR 尽可能详细的描述基金信息，例如：需求文档地址、本次功能改动点、设计思路、技术方案地址等，推荐接入 MR 模版。

2. Owner 成功发起 MR 后，需在 prowork 上指派任务给相应的 reviewer，任务需注明 MR 地址 及 开发周期。

3. Reviewer 基于 MR 进行 code review，如对 MR 有任何问题，发起 Diss，review 完成后知会 Owner 结果，如有 Diss，Owner需对每个 Diss 进行回复，直至所有的 Diss 状态变为 resolved，可进入提测阶段。

4. 如果测试或者验收环节发现问题，Owner 需对代码进行修改，需发起新一轮的 MR, 直至测试环境代码验收通过。

5. 确认代码可发布至生产环境，知会项目负责人合并代码进行发布。

写在最后

代码 review 的目的是为了保证项目代码的健壮性、规范性，同时达到业务/设计共识。review 不是批判，针对 review 给出的 comment，你觉得有不合理的建议，可以详细的说明自己的看法及原因；reviewer 持有的观念并不一定是合理的，reviewer 注意友好 comment，具体什么问题，应该怎么解决，可以给出适当的范例；对于比较好的代码，也可以给出足够的赞美。review 是一个相互学习的过程，享受 review，见贤思齐，不贤而自省。