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