如果说git终于让工程师在合作撰写代码的过程中找回了丢失已久的乐趣,那么,code review的过程还是让人相当地抓狂。我用过的所有code review的工具,没有一款能让code review的过程轻松起来。
公司内部使用的工具自不必说,那是反人类的极致体验。
reviewboard和gerrit不那么反人类,但submit review和review的流程也不太方便,而且体验并不一致。submit review可以在命令行下方便地完成,但review需要点开邮件通知里的链接才能查看。如果你一直在代码上工作,而不查邮件,你可能会miss掉一些review。
不过,这些体验上的问题都是细枝末节。目前已有的code review工具的最大问题是:它不是写给程序员用的!慢着,这话听着好耳熟?没错,Linux Tolvalds在撰写git的时候,就说svn最大的问题是这玩意儿不是写给程序员用的。
如果要我设计一款code review工具,它的使用体验会类似这样:
$ git commit -a
$ git push
Done! 不需要更多的流程了。
这里面隐含了如下步骤:
与之最接近的体验是gerrit:
$ git commit -a
$ git push origin HEAD:refs/for/master
但,HEAD:refs/for/master
究竟是什么,我想没多少人能搞懂。如果配置了一个repo必须要经过code review后才能push到服务器,那么,为何不直接把git push
用做review的命令?
蒂尔原则:code review应该和repo紧密相连,而不是那该死的邮件。
当reviewer在同样的repo下运行git status
时,会有如下提示:
$ git status
# On branch master
nothing to commit, working directory clean
You have 2 reviews:
6ae24fe: PR12345 - can not connect to server, by Tyr Chen
723e9e2: PR12346 - Tracking feature 123: add queue support, by Tyr Chen
You must run "git review <review-id>" to do review.
这个提示很恼人,一般git用户都会尽快完成review以便让git status
的输出看上去干净些。如果review长时间得不到处理,其颜色每隔4个小时变红一些,直至鲜红。
Reviewer可以运行git review
进行代码review:
$ git review 6ae24fe
根据配置,这条命令会自动调出对应的代码比较工具,比如说vimdiff
。如果没有指定,则会输出标准的git diff
。
代码阅读完毕,可以使用:
$ git review 6ae24fe --approve|reject
这会弹出一个form,填写review的意见。
被round robin出的2-3个reviewers必须全部approve,这个review才算通过。如果某个reviewer在72小时内还没有review代码(可能休假去了),则相应的review自动被approve,review的注释是:"review skipped automatically due to XXX not-responding"。这就像信用记录,对于一个程序员来说,如果他review别人的代码总出现这样的日志,自己脸上也挂不住。
此外,review服务器还记录和索引每个review,方便日后检索。以后如果哪个问题是由某次不正确的修改导致的,那么能够很快查询到是谁批准了这段代码。
最后,review的数据最好能做visualization,每个程序员都能看到他的历史review图表(这个可以做得非常有意思),也可以看到各种各样的统计信息(比如说团队里提交代码的排行榜,review通过率排行榜,review大牛排行榜等等),让冷冰冰的code commit和code review活泼起来。
投票:如果有这样一个code review工具,你会试用么?回复即可。:)
如果您对本站的文章感兴趣,欢迎订阅我的微博公共账号:程序人生。每次博文发表时,您都能获得通知。此外,公共账号还会不定期推送一些短文,技术心得,供您参考。