这是一个创建于 174 天前的主题，其中的信息可能已经有所发展或是发生改变。
- code review 的流程
- code review 的频率
22 条回复 • 2024-07-12 14:42:33 +08:00
 |
1
CEBBCAT 174 天前
问得有点儿宽泛呐。有的项目是走个流程，有的项目是偷天换日，有的是能在测试结束后还能看到数个隐含或强 bug 。
之前的经历来说，大概都是一 merge 一 review ，零星几次才会定期 review 近期代码 |
 |
3
qxdo1234 174 天前
我们之前的经验来说，是开始测试之前，大家一起。作者给其他人讲一下需求背景，技术方案是怎么样子的，再结合测试或其余开发，具体落到细节上，比如数据库表设计，接口设计，或者是数据怎么存储，然后 某些地方会有些问题，或者是注意事项，抛出来大家一起帮你看看如何解决，人多力量大，别人学你的代码 也是一种进步，你给别人讲明白，也是个进步。
|
 |
4
estk 174 天前 via iPhone
ci/cd 呗
|
 |
5
Pantheoon 174 天前
我们这强制做 CR,还需要拉一堆人,这些人里面绝大多数都不知道需求和实现逻辑,一次迭代可能几千行代码,结果可想而知,参会的人挂着听下,发起的人讲下走下过场
|
 |
6
liprais 174 天前
没啥用
一切以测试结果说话 |
 |
7
klo424 174 天前
专门一个人去 review ，后续代码质量稳定了，就不做了。
|
 |
8
ruyan2013 174 天前
其实这种最好还是根据团队具体情况来，主要看程序员水平、项目紧急情况、项目重视程度、是否有单测/E2E/人肉测试、团队成员是否有时间/有能力做 review....
简单点的也可以只 review 一个代码整体流程，细节的东西真的得看人，光一个 review 发现的问题也只是部分 |
 |
9
ArmsZ 174 天前  2
一般每周一个人轮流去 review ，看代码规范和 git 提交记录实现，然后把不妥的贴出来。会上直接说。
|
 |
10
liuliancao 174 天前
crucible 或者 gerrit 吧
|
 |
11
unco020511 174 天前
每次代码合入受管控分支时需要审批代码后才能合入
|
 |
12
sockpuppet9527 174 天前 3
1. code review 的流程
我本人做 code review ，得细分看什么类型的 pr ，如果是 fix 类的 pr ，那么只做逻辑上的验证即可。 但如果是 feature 类的 pr ，会先把 branch 拉下来，看本身测试 case 跑一下。然后找到"入口"，一般来说都是接口，如果不是接口，那么回想着能不能改成接口？ 有了"入口"之后，那么基本就是接口->实现->调用者这样去看，我会一行行读，主要看几个方面 - 当前接口在哪个层级？放得位置是否合理？抽象接口做的是否足够合理？ - 实现函数是否合理？注释/命名是否符合目前的 code style ？参数和返回是否能改的更合理？ - 当前实现逻辑是否正确？是否存在风险？参数有无验证？ - 是否存在极端 case 出现问题？ 当然还有很多，一时半会可能总结不出来，但如果你让别人多 review 你的代码，你也能找到自己的经验 2. code review 的频率 每个 PR |
 |
13
huyangq OP |
 |
14
Chinsung 172 天前
这玩意永远是一个投入产出比的问题，做法是次要的，做法就是走 merge request 做每次提交的 CR 后合并，要么就是定期开 CR 会
第一个保证的是代码质量和低级问题，还有统一的代码规范 第二个就是提升大家整体代码的意识，提升团队技术氛围 做 CR ，形式和方法都不重要，成本才重要，落地和加入项目流程的成本项目组愿不愿意承担，结果效果可不可视化以至于是否能让相关方愿意承担，有没有这个必要性以使得所有相关方愿意承担 |
 |
15
jipaidian 171 天前
推不动，还在想策略，现在每个项目需求都来不及，基本上也没多少时间做集中代码检视（指 3 个人以上），但是又有指标要求，真的是。。。
|
 |
16
rccoder 171 天前
先问下自己，如果自己来 Review ，能不能做到每天至少认真看几个 MR
如果做不到，那就放弃这个想法 如果能做到，那就自己带头主动推进，从自己先做出示范效果，并且至少坚持 2 个 Q 。CR 的核心从来不是流程或规范的问题，永远都是推进人是否能影响团队氛围的问题 |
 |
17
zhuangzhuang1988 171 天前
不做，
人员认知不一样 我认为这样写好，标准， 看得人说看不懂。 别的认为那样写好，我说我看不懂。。 |
|
18
sockpuppet9527 171 天前
@huyangq #13
如果读的顺畅了，那速度会很快。跑 case 的话，我有个环境专门来验 case ，一套脚本拉下来+编译+跑 case 10~20 分钟左右。 目前我工作上做 code review 时间大概是 2 ~ 3 成左右，我之前同事，某个开源的 maintainer ，他的 code review 时间大概要占在 5 成左右。基本年长一些的同事都是占这个值。 我个人是拥护 code review 的，code review 带来的好处是去追赶进度/盲目重构不可比的。 |
|
19
sockpuppet9527 171 天前
@sockpuppet9527 #18 另外想补充一些，目前应该知名一些的开源项目都是需要每一个 PR 进行 review 的。
|
|
20
huyangq OP 连自测的时间都不怎么够
然后 测试出问题量比较多 还怪代码质量不行 不知道脑子怎么想的 |
|
21
huyangq OP 看了大家的 回复
看来还是得看实际情况，有没有时间，有没有能力 |
Select Language