大家 code review 是如何做的？

[huyangq]

• code review 的流程
• code review 的频率

[CEBBCAT]

问得有点儿宽泛呐。有的项目是走个流程，有的项目是偷天换日，有的是能在测试结束后还能看到数个隐含或强 bug 。

之前的经历来说，大概都是一 merge 一 review ，零星几次才会定期 review 近期代码

[CEBBCAT]

@CEBBCAT #1
> 有的是能在测试结束后还能看到数个隐含或强 bug

指在 review 中发现了问题，避免了上线后的问题

[qxdo1234]

我们之前的经验来说，是开始测试之前，大家一起。作者给其他人讲一下需求背景，技术方案是怎么样子的，再结合测试或其余开发，具体落到细节上，比如数据库表设计，接口设计，或者是数据怎么存储，然后 某些地方会有些问题，或者是注意事项，抛出来大家一起帮你看看如何解决，人多力量大，别人学你的代码 也是一种进步，你给别人讲明白，也是个进步。

[estk]

ci/cd 呗

[Pantheoon]

我们这强制做 CR,还需要拉一堆人,这些人里面绝大多数都不知道需求和实现逻辑,一次迭代可能几千行代码,结果可想而知,参会的人挂着听下,发起的人讲下走下过场

[liprais]

没啥用
一切以测试结果说话

[klo424]

专门一个人去 review ，后续代码质量稳定了，就不做了。

[ruyan2013]

其实这种最好还是根据团队具体情况来，主要看程序员水平、项目紧急情况、项目重视程度、是否有单测/E2E/人肉测试、团队成员是否有时间/有能力做 review....

简单点的也可以只 review 一个代码整体流程，细节的东西真的得看人，光一个 review 发现的问题也只是部分

[ArmsZ]

一般每周一个人轮流去 review ，看代码规范和 git 提交记录实现，然后把不妥的贴出来。会上直接说。

[liuliancao]

crucible 或者 gerrit 吧

[unco020511]

每次代码合入受管控分支时需要审批代码后才能合入

[sockpuppet9527]

1. code review 的流程

我本人做 code review ，得细分看什么类型的 pr ，如果是 fix 类的 pr ，那么只做逻辑上的验证即可。
但如果是 feature 类的 pr ，会先把 branch 拉下来，看本身测试 case 跑一下。然后找到"入口"，一般来说都是接口，如果不是接口，那么回想着能不能改成接口？

有了"入口"之后，那么基本就是接口->实现->调用者这样去看，我会一行行读，主要看几个方面
- 当前接口在哪个层级？放得位置是否合理？抽象接口做的是否足够合理？
- 实现函数是否合理？注释/命名是否符合目前的 code style ？参数和返回是否能改的更合理？
- 当前实现逻辑是否正确？是否存在风险？参数有无验证？
- 是否存在极端 case 出现问题？

当然还有很多，一时半会可能总结不出来，但如果你让别人多 review 你的代码，你也能找到自己的经验

2. code review 的频率

每个 PR

[huyangq]

@sockpuppet9527 强度这么大啊 每个 PR
而且你还一行行读代码 还甚至拉下来 跑 case
这样的话 岂不是工作量巨大

[Chinsung]

这玩意永远是一个投入产出比的问题，做法是次要的，做法就是走 merge request 做每次提交的 CR 后合并，要么就是定期开 CR 会
第一个保证的是代码质量和低级问题，还有统一的代码规范
第二个就是提升大家整体代码的意识，提升团队技术氛围
做 CR ，形式和方法都不重要，成本才重要，落地和加入项目流程的成本项目组愿不愿意承担，结果效果可不可视化以至于是否能让相关方愿意承担，有没有这个必要性以使得所有相关方愿意承担

[jipaidian]

推不动，还在想策略，现在每个项目需求都来不及，基本上也没多少时间做集中代码检视（指 3 个人以上），但是又有指标要求，真的是。。。

[rccoder]

先问下自己，如果自己来 Review ，能不能做到每天至少认真看几个 MR

如果做不到，那就放弃这个想法

如果能做到，那就自己带头主动推进，从自己先做出示范效果，并且至少坚持 2 个 Q 。CR 的核心从来不是流程或规范的问题，永远都是推进人是否能影响团队氛围的问题

[zhuangzhuang1988]

不做，
人员认知不一样
我认为这样写好，标准， 看得人说看不懂。
别的认为那样写好，我说我看不懂。。

[sockpuppet9527]

@huyangq #13

如果读的顺畅了，那速度会很快。跑 case 的话，我有个环境专门来验 case ，一套脚本拉下来+编译+跑 case 10~20 分钟左右。

目前我工作上做 code review 时间大概是 2 ~ 3 成左右，我之前同事，某个开源的 maintainer ，他的 code review 时间大概要占在 5 成左右。基本年长一些的同事都是占这个值。

我个人是拥护 code review 的，code review 带来的好处是去追赶进度/盲目重构不可比的。

[sockpuppet9527]

@sockpuppet9527 #18 另外想补充一些，目前应该知名一些的开源项目都是需要每一个 PR 进行 review 的。

[huyangq]

连自测的时间都不怎么够
然后 测试出问题量比较多 还怪代码质量不行
不知道脑子怎么想的

[huyangq]

看了大家的 回复
看来还是得看实际情况，有没有时间，有没有能力

[GPT6]

https://github.com/bestK/gitea-ai-codereview