新手问题 如何 code review?求推荐好的工作流程

xiaoronglv · 2014年06月02日 · 最后由 xiaoronglv 回复于 2014年06月03日 · 5126 次阅读

最近和同事 code review 时遇到一点问题,假如他提交了一个分支,共 10 个 commits。

我可以按照两种方式阅读代码:

  1. 一次性的拎出所有的 modified files,统一阅读所有的代码。
  2. 按照作者的思路,逐个阅读 commit,最终读完所有的代码。

第一种方式遇到的问题

把两个分支不同的文件挑出来很费时间(可能有 20 个文件)。至少 Gitlab、Tower、SourceTree 都做不到。

第二个方式遇到的问题

同一个文件频繁被修改,我压根不关心作者的心路历程,我只关心最终的代码是什么样子。

每每 review 代码,我都有这种感觉。

#1 楼 @Rei

你喜欢哪种方式?

#2 楼 @xiaoronglv review 得不多,好像统一 review 比较好。逐个 review 有时会看到个错误,想要评论,发现下一个 commit 修复了,这就浪费时间了。

我一般是统一 review,如果遇到看得不太懂的代码,再拿单独的 commit 来理解作者的编码过程

当只 Review10 行代码时,每个人都会看的很认真。当要 Review 100 行代码时,大家会说:“看起来不错啊。”

我们现在大多数是用 2 的方式来 review,结果固然重要,但心路历程有时候更能反应很多的问题和经验教训啥的,所也我们有时候也关心。但是 2 对于 Commit 的组织,大小,原子性,有可能要求更高,我们 Team 中比较注重这些,所以感觉还好。但是有的时候也用 1 的方式,但一般都是碰到比较大的变动的时候,但是其实感觉还是上边说的那些没做到位。

对于 @Rei 提到的情况我们也会碰到,不过我们都是 Team 每天找一段时间一起围着一台机器 Review,所以一般发现错误如果已经被后边修了,“当事人”就会直接解释一下,顺便还能给大家提个醒,感觉还好。

git diff master...feature

#3 楼 @Rei Review 的时候让作者引导怎样?

#10 楼 @Rei 异步啊,那就难了。还是约个时间做集体 Review 比较好。

diff 一下不就好了 每个人写 feature 的时候单独开 branch 这样可以做一个大的 diff 直接比较出自己所有的改动

话说说道 review 的问题了,论坛里有用Phabricator来做 code review 的吗?可否和 pull request 比较一下?

就是@zj0713001 这么弄就好了。哪里有时间一个个 commit 去探索心路历程。

选 1 并且用 github 或者 bitbucket 来看 diff,我只看重结果,有 comments 也是针对结果而不是过程。去年写了一篇文章 http://yedingding.com/2013/08/08/dig-into-code-review-process.html

多谢大家的建议,霍然开朗,嘿嘿。

各位亲,Gitlab 在审核 PullRequest 时 可以一次把两个分支所有的差异全捞出来,真不错。

diff

文件修改列表

需要 登录 后方可回复, 如果你还没有账号请 注册新账号