前提
1、项目已接入公司代码规范,CR 过程中不纠结代码风格,借助pre-commit 关联 lint,避免代码中出现的debugger、console等...
2、接入 husky,规范commit message
-
feat:新特性
-
fix:修复bug
-
chore:优化,如项目结构,依赖安装更新等
-
docs:文档变更
-
style:样式相关修改
-
refactor:重构
一、角色职能
author:需求开发者
-
对复杂业务写明相应注释,MR 根据MR模版填写基础信息,便于 reviewer 理解。
-
对于 reviewer 提出的comment,及时响应,完成 comment 修改后及时反馈,commit 提交信息备注,如 review:xxx,保证复检效率。
-
小批量、多批次提交,每次提交的 review 的代码量要少,commit 写明具体提交背景。
reviewe:cr 参与者,一般有项目负责人或项目参与者组成
-
说明 comment 等级,reviewer 对相应的代码提出评价时,需要指明相应等级,如
-
[ fix ]:xxxxx;此处需强制修改,提供修改建议。
-
[ advise ]:xxxxx;此处主观上建议修改,不强制,可提供修改建议
-
[ question ]:xxxxx;此处存在疑虑,需要 author 作出解释
-
-
在不影响自我工作的前提下,尽快响应,拆分 review 粒度,使快速响应成为可能。Google 的中位数是 4 小时,最大不要超过 1 天。
二、CR 标准
-
代码注释(复杂 特殊业务逻辑 文档等)
-
代码可读性(过多嵌套、冗余、变量命名,功能独立等)
-
代码扩展性(模块拆分 / 设计合理)
-
遵守 review 范围,原则上只针对此次改动范围进行 review
三、CR 流程
1. self-review
-
MR 基础信息是否填写完整
-
Owner 确认已完成充分自测
2. CR
-
Owner 启动开发时发起 CR,需求任务关联 reviewer,MR 尽可能详细的描述基金信息,例如:需求文档地址、本次功能改动点、设计思路、技术方案地址等,推荐接入 MR 模版。
-
Owner 成功发起 MR 后,需在 prowork 上指派任务给相应的 reviewer,任务需注明 MR 地址 及 开发周期。
-
Reviewer 基于 MR 进行 code review,如对 MR 有任何问题,发起 Diss,review 完成后知会 Owner 结果,如有 Diss,Owner需对每个 Diss 进行回复,直至所有的 Diss 状态变为 resolved,可进入提测阶段。
-
如果测试或者验收环节发现问题,Owner 需对代码进行修改,需发起新一轮的 MR, 直至测试环境代码验收通过。
-
确认代码可发布至生产环境,知会项目负责人合并代码进行发布。
写在最后
代码 review 的目的是为了保证项目代码的健壮性、规范性,同时达到业务/设计共识。review 不是批判,针对 review 给出的 comment,你觉得有不合理的建议,可以详细的说明自己的看法及原因;reviewer 持有的观念并不一定是合理的,reviewer 注意友好 comment,具体什么问题,应该怎么解决,可以给出适当的范例;对于比较好的代码,也可以给出足够的赞美。review 是一个相互学习的过程,享受 review,见贤思齐,不贤而自省。
标签:comment,中级,代码,经验之谈,MR,Owner,reviewer,review From: https://blog.csdn.net/hebtu666/article/details/126948572