各位团队的 codereview 是在提交到代码库前还是后做的呢?
如果提交前做,那么开发进度就要受 reviewer 的时间影响。
review 前做,一般都是“ hi 我提了一个 review,因为等着合并测试,麻烦快点”。但 reviewer 不一定有时间啊,或者需要大量的时间研究别人的代码,因为催,导致 review 效果下降。
如果提交后做,怎么确保 review 的意见会被整合到代码库中?
因为代码已经提交了,可能进入到下一轮测试甚至上线了,没有什么好的强制措施不让代码上线。你总不能说各个团队已经测试好了,因为你的 review 没过不让上线吧?
或者代码提交之后已经投入资源做进一步测试,这个时候依据 review 结果再修改,可能之前的测试就都白费了。
另外问下用什么工具做 review 体验比较好?我们现在用的是 gitlab,但一旦是一个大提交,页面卡得动不了。
1
Tonni 2018-12-05 12:13:18 +08:00 1
commit -> pull request -> code review -> merge.
> 如果提交前做,那么开发进度就要受 reviewer 的时间影响 所以要把 code review 算到开发进度估算时间里面。 > 如果提交后做,怎么确保 review 的意见会被整合到代码库中? 线上紧急情况可以发一个 pull request 测试功能正常后直接合并,上线后再去 pull request 上面 review。先上车后补票。 |
2
wdv2ly 2018-12-05 12:17:12 +08:00 via Android
提交后,合并前,进行
|
3
insomnia1232 2018-12-05 13:22:56 +08:00
肯定 merge 前做 merge 后做还有什么意义 提交太大就任务分的有问题 没有足够细化
|
4
laike9m 2018-12-05 13:42:11 +08:00 via Android
异地 review 确实会影响效率,但有时候也没办法
|
5
maichael 2018-12-05 13:44:24 +08:00
1. 提交后,合并前做 review。合并测试可以在合并前就做。
2. 合并后再做 review 的效果会很差。 3. 有大提交的存在说明持续集成执行的有问题的。用什么工具都好,大提交对于 reviewer 的体验都很差。 |
6
coderluan 2018-12-05 13:50:33 +08:00
一般分两个分支或者两个库,一个 dev,一个 release,dev 随时提交随时测试随时合并,release 只放 review 和全面测试之后的代码,最后只保留 release 部分。
|
7
cjw1115 2018-12-05 13:52:22 +08:00
现在基本流程是
从 main branch 出 dev ---> dev 上写代码 ---> submit ---> code review ---> merge main to dev ---> resolve conflicts ---> merge dev to main |
8
th00000 2018-12-05 13:56:48 +08:00
merge 前做
如果有人把 rm -rf / 提交进代码库了怎么办 |
9
xiubin 2018-12-05 14:02:00 +08:00
merge request -> review -> 提测 -> 测试通过 -> merge into master
|
10
clino 2018-12-05 14:04:05 +08:00
我们合入前经过 code review 改个四五次以上也有不少,一般都会改个两三次
|