需要什么样的代码审查方法？
公司最近严控代码质量，代码审查（Code Review）相应地也就多了起来。每天常常收到好几封代码审查的邀请邮件，每封邮件都包含了需要审查的代码附件，这些附件的压缩方式还是各式各样的都有，7z, zip, rar等等，附件中还有一个用来填写评论（Comment）的Excel表格。直到上周的有一天，我公司邮箱不小心又被爆仓了，收件箱按照附件排列一看大多是代码审查相关的邮件，终于对这种工作方式受不了。
先说说这种目前这种代码审查的方法有都么的繁冗。每次我收到这种邮件，第一步是把附件保存到一个临时的目录，第二步是把这个附件解压缩，第三用Beyond Compare把解压缩出来经过改动的文件进行比较，第四步开始审查代码然后把评论记录到Excel里面（这其中需要填写源代码文件，代码行，评论，问题等等），第五步是把评论过发回给代码审查请求者。第六步，通过邮件和请求者对评论做进一步的交流。
而请求代码审查的工程师则需要做更多的事情：第一步，需要从代码目录树中抽取改动的文件放到一个文件夹里面，第二步，把对应版本未作改动的文件放到一个文件夹，第三步，把这两个文件夹压缩然后。第四步，撰写代码审查的邀请邮件并发送给审查者。第五步，收集各种评论；第六步，对评论Reject或者Accept并通过邮件做进一步交流，第七步，改动代码并发出来重新审查，然后重复流程；最后全部流程完毕才可以提交代码。
可以看到，这种代码审查的方式有很多的弊病：
- 不可以被检索、跟踪和统计；有的评论全部放在Excel里面，Excel文档又放在内部的某个服务器里面；
- 尽可能避免评论，因为评论方式复杂，审查的软件工程师不是那么重要的问题就直接忽略；
- 跳过代码审查，软件工程师可能因为流程繁冗，直接跳过代码审查而把新改动的代码提交到代码库里面；
- 审查效率低下，从代码审查请求发起到代码审查一直不断陷入操作和流程，蚕食着工程师代码审查时间和精力；
这是一种小作坊式的代码审查方法，比较专业的说法是Mail Pass Code Review。而目前大的软件公司和项目更多地采用的是协同式的代码审查工具，比如大名鼎鼎的开源工具Review Board以及商业软件Crucible，使用这些工具的好处显而易见。在我受不了的那一天，我把Review Board安装到本地的虚拟机上，然后尝试用这个工具来审查最近改动的代码，顿时觉得精神气爽。
在使用Review Board的过程中，上诉代码审查的弊病完全都可以避免。它还可以和代码库集成在一起，自动的生成改动代码的diff文件，可以在浏览器端直接在diff文件内置评论；可以针对每个评论提一个问题，只有问题被解决才可以把这个问题关掉；可以在浏览器端跟踪所有代码审查请求的状态，最重要的是它跟代码库集成在一起之后，可以让工程师的每次代码提交（commit）强制执行代码审查，从而提高代码质量。
CEO一再声称，让公司成为Software Driven的科技公司，从目前代码审查的工具使用这点来看，道阻且长。
附录：