有时候，做为一个程序员，我觉得我的职业生涯会被我开发软件使用的开发工具和技术架构明显的分割成几个阶段。一部分是因为使用的编程语言——在大学时是 Smalltalk，在Gog Creek公司是C#和Python，而另一方面是开发工具。我在Fog Creek公司里工作了8年，在那里，我们有一个非常固定的技术架构：bug管理、客户支持和文档管理用 FogBugz；开发管理用 Trello；代码审查用 Kiln；版本控制用 Mercurial；编码用Vim和 Visual Studio ；持续集成用我们的内部工具Mortar；随着时间的流逝，这些工具在慢慢的变化，但变化从来都是缓慢逐步的，一个组件一个组件的。所以，我的工作流程和工作效率一直没有巨大的变化。
大概一个月前，我加入了 Knewton公司，整个技术架构一下子完全变了。Visual Studio换成了 IntelliJ；Mortar换成了 Jenkins；Mercurial换成了Git；FogBugz换成了 JIRA。
也许你会觉得这会让我头大，还会有些不知所措，但事实上并不是这样，这些工具的改变并没有对我的工作流程产生多大的影响。我发现Git和Mercurial惊人的相似，JIRA基本上是一个半成品的FogBugz，而IntelliJ算是和Visual Studio差不多吧。也许我需要从新学习一些快捷键和了解按钮的位置，但事实上我的开发模式没有实质的变化。
但有一个例外：我不喜欢使用 Gerrit做代码审查。不喜欢它的原因并不是它的程序写的很烂；不喜欢的原因是它的流程会鼓励一种不良编程习惯。
Knewton公司对代码审查非常、非常的看重。这非常好，因为我也是这样，而且我开发过整套关于代码审查的工具。所以，我的意思绝对不是反对代码审查。
而且，Gerrit的设计跟最初的 Kiln 原型的设计几乎完全一致。代码审查的实施有两种基本的方式： pre-merge，是指在代码进入主代码库之前进行代码审查。和 post-commit，是指之后审查。新版本的Kiln对两种方式都支持，但在2008年，当Tyler和我通过一个项目——也就是Kiln的前身——在Django Dash中取胜时，我们俩都认同pre-merge的工作流程。直接提交到主代码库是不允许的；你需要先创建一个审查区，把修改的代码放进去，讨论，然后，等待批准，系统会自动合并这些代码。这一种是我最欣赏的工作流程，所以Kiln一直支持这种方式(通过“Read and Branch”权限)，而巧的事，这也是Gerrit唯一支持的方式，按理说我应该喜欢它才是。
我差一点就喜欢它了，但问题出在一个致命问题上： 代码审查的粒度。在Kiln中，审查是基于 被修改的相关代码。而在Gerrit里，审查是基于 单次代码修改提交。在Kiln中，一个单一审查会涉及很多次代码提交，审查的批准和拒绝是整体的，而Gerrit里审查的是一次孤立的提交。
这两种方法模式在各自的阵营里都有大量的受欢迎的系统实现。GitHub和Bitbucket都和Kiln一样都属于“批量提交”审查阵营，而Review Board, Barkeep, 和 Phabricator 都加入了“单一提交”审查阵营。所以，情况并不是我所说的某一种方式、某一款软件是对的，而其它都是错的。但我还是要坚持说，批量审查的方式是对的，而其余的都是错的，因为 单一提交审查系统在鼓励一种不良编程习惯。
单一提交审查系统有两个最根本的问题：
这就是我为什么对Gerrit极度失望的原因。并不是Gerrit是一个糟糕的软件，而是他在鼓励一种在使用版本控制时不良的开发习惯。这就是为什么所有工具中唯独不喜欢它的原因，是唯一让我对放弃Kiln感到失望的系统。
本文由 外刊IT评论网( www.vaikan.com)原创发表，文章地址： 代码审查和不良编程习惯，[英文原文： Code reviews and bad habits ]