2015061808 - 代码审查的必要性

    转载地址已经忘记.

    作者讲述了一家公司需要实施某个非常重要的模块，但是高级开发人员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（中级开发人员）。