代码审查和不良编程习惯

出自http://www.apkbus.com/android-6752-1.html

批量审查的方式是对的，

因为单一提交审查系统在鼓励一种不良编程习惯。

单一提交审查系统有两个最根本的问题：

1. 它在向你暗示各个修改提交之间没有关联。经常的，每当我实现一个新功能时，我都会有三个步骤：首先，重构现有的代码，让代码整洁，方便添加新功能；接下来，加入新功能；最后，写单元测试代码。功能越复杂，各个步骤里越有可能各自包含多个逻辑步骤。如果能将多个不同的提交放的一个代码审查中进行，那你就可以简单的将这些修改分组提交。但如果使用的是单一提交审查系统，那就是在迫使我将所有修改全部完成后进行一次全量提交。这样一来，重构的代码，新添加的代码，都混在一起，让人非常不爽，而且在审查过程中需要我付出大量额外的精力来指出各部分代码都是干嘛的。你也许会争辩，说你可以把修改的代码拆分提交，每一个提交对应一次审查。但事实上这样做会更糟。最好的情况下，你可以把测试程序和新功能代码分开提交，可以把重构代码和后加代码分开提交，但真正的问题是，众多的单一修改审查系统都怂恿对某个提交在孤立的状态下进行批准，这完全会和你的愿望相反。于是，“一次提交一次审查”的折中就从“麻烦”变成了“危险”。的确不是一种改进。
2. 它在怂恿你隐藏历史记录。版本控制系统的最重要的功能就是告诉你代码演变的历史、是如何变成今天这个样子的。我经常会查看昨天代码是什么样的，上周二下午2点代码是什么样的，期间发生了什么变化。很多时候是因为我发现代码以前好用而现在不行，我想知道为什么。而更多时候，我是想知道为什么会对代码做这样的修改。关联的上下文是什么？动机是什么？如果你总是保持所有代码一次提交——为了审查，那我就丧失了很多历史信息：所有我能找到的就是一次完整软件的一次提交，完全没有开发过程中的过程信息。

这就是我为什么对Gerrit极度失望的原因。并不是Gerrit是一个糟糕的软件，而是他在鼓励一种在使用版本控制时不良的开发习惯。这就是为什么所有工具中唯独不喜欢它的原因，是唯一让我对放弃Kiln感到失望的系统。

[英文原文：Code reviews and bad habits ]