标签：
前些天有人写了一篇超精彩的博客贴子，是关于之所以要将优秀的程序员从平庸的群体中挑选出来的重要性。这篇文章写得真的很好，因为它讲述的情况和产生的可怕后果，在我的职业生涯中我已经见得太多太多了，不过这其实是很容易阻止的。作者讲述了这样一种现实情况——一家公司需要实施某个非常重要的模块，但是此时它的高级开发人员 Mr Senior 很忙。因此，他们将模块给了新手 Mr Newbie——他花了 4 个月来写模块，两个星期的时间来修复 QA 发现的大量 bug，浪费了技术支持无数个小时用于揪出 QA 没有发现的 bug，甚至导致客户以软件满是 bug 为由取消了合同，等等。最终，高级程序员站出来，用了一个月的时间从头重写，然后在经过 QA 快速的检查之后，一个几乎没有 bug 的版面世了，所有人都很满意。
结局很圆满，没错，但是不知道你看出来没有，其实所有的问题本来都是可以避免的，只要这家公司能够在日常研发中引入代码审查程序。
现在，在我解释如何避免这些问题之前，我想先描述一下我认为一个好的代码审查程序应该是什么样的。所有它需要做的就是遵循以下两个简单的原则：
这两个原则貌似有违直觉。你或许要问了：“为什么不能相信高级程序员编写的高质量代码？”又或是，“如何相信新手程序员审查后的代码确保是 OK 的？”
第一个问题其实是不应该问的，因为即使是最资深最高级的开发人员也会时不时地犯错。虽然手工的代码审查永远不可能像自动化测试和脚本化的手动 QA 那样严谨，但是代码审查执行所需的时间更短，并且很容易发现自动化测试理解不了的问题——通常是位于架构层面的问题——这要是拖到以后修复就会变得很难很难。
至于第二个你不信任新手程序员的问题——答案很简单。多一双眼睛来检查代码总是令人喜闻乐见的，但这也不是主要原因。我们真正想要实现的目的是提高初级程序员的技能。在审查时，他可以知道这些高级开发人员是如何编写代码的。最重要的是，这将有助于他理解如何批判性地阅读别人的代码，一两个月后，他甚至能够审查自己的代码，从而提高了他最终提交到存储库中的代码质量。
现在让我们回过头去再看前面作者提到的案例，我们可以发现，如果 Mr Newbie 写的代码能够拿给 Mr Senior 去审查，那么他很多初始的错误在他第一次提交时就会被发现，甚至他还可以向 Mr Senior 请教和讨论模块，从而创造出一个更好的架构，也许都不用像原来那样花上 4 个月的时间就可以完成任务。此外，Mr Newbie 由于知道需要经过高级开发人员的眼睛，因而在写代码时会严格要求自己，用批判的眼光看自己的代码。而最重要的好处是，整个过程会教会 Mr Newbie 很多关于 Mr Senior 思考的方法，也许等到构建下一个模块时，他已经成为了 Mr Intermediate（中级开发人员）。
标签：