代码检视（Code Review）的几种实践

代码检视每个读次文章的人都会知道是什么意思。我们项目也是坚持在做代码检视。今天我们仔细深入看看代码检视的内涵及作用。

这几年，我用过不同的代码检视工具，并且我相信有一套代码检视方法是最好的，下面是我所学到的。

有三种代码检视的方法：

• 无代码检视

每个开发者自由的check in代码，且每个人都可以检查check in代码的功能清单，只要他愿意，没有责任与义务的区分。

• 非阻塞式代码检视

当代码check in后，检视者根据修改清单，在某个时间点到代码库上去检视修改的代码。这种检视方式不能阻止坏的代码被check in到代码库上区。

• 阻塞式代码检视

这种检视方式式代码提交者通知检视者检视代码，代码在没有得到检视者同意之前不能提交到代码库。

让我们先来看第一种无代码检视，我坚持认为没有代码检视的软件开发，最终将会是一堆烂代码，不管程序员有多牛多有经验。即使你是很牛的程序员，你不可能在所有时间都输出高质量代码。月有圆缺，潮汐有涨落，程序员交付的代码质量也符合这个规律的。

当使用阻塞式检视方法的时候，代码提交者不能提交代码，除非监视者认为代码质量已经符合要求。

当使用非阻塞式检视方法的时候，代码会被立即提交到代码库，但是检视者可以在受到通知后检视代码，我建议做一个提醒系统，不断提醒那些懒惰的检视者要完成代码检视。

按照我的经验来看，非阻塞式的代码检视是可行的，在讨论这个之前，我们先讨论一下代码检视到底能做什么。因为我发现很多次人们从感觉上认识到的代码检视的作用，与实际的不一致。
这里有几点事实：

• 代码检视不能发现你代码中的严重bug

听到这个你会很沮丧，但这是现实。当你的项目越来越复杂的时候，你做了一个更改，你不能从检视者那里得到一个意见，说：如果servlet接受20个请求，死锁将会发生在A.java的723行和B.java的1410行”。取而代之的是，你会觉得代码检视者的意见像是花瓶，可有可无。

• 代码检视者能够督促你认真写代码

你知道你的代码将会被很多双眼睛盯着，所以你会花额外多的时间让代码可读性更好。

我发现赞成阻塞式检视方法的人，通常会觉得太多自由是导致代码质量差的原因。有一种观点是：如果检视者不带着一种强烈的责任感去检视代码，那么检视者就会松懈然后检视就完成不了。
首先，我的经验告诉我，这个观点是不正确的。我发现在使用非阻塞方法的项目中，检视者也非常努力的检视，通常在少于一周的时间完成检视任务。
不过，不管观点的支持方还是反对方，都存在一个固有的缺陷：我们没有认识到阻塞式检视和非阻塞式检视都式依赖你的团队（或者项目的检视规则）。

在阻塞式检视场景下，当你要提交代码时候，你依赖于检视者，他要意识到你一直在等着他来检视代码，除此外没有别的事情可做。如果不是有这个压力在，监视者可能要几天之后才能检视你的代码，因为他可能别检视任务淹没了，可能他会认为代码提交者会找一些其他事情做，为了在等待检视的时候不闲着。

我们可以汇总阻塞式检视的问题：
我没有实践过阻塞式代码检视，这些问题是从实施阻塞式代码检视的团队中反馈出来的。

• 等待检视完成的过程中，开发者被阻塞了，什么事情也干不了。
• 开发者会一次尽可能提交多的代码，因为他们不想经常被阻塞，经常被中断。
• 代码太多了会给检视者带来问题，他们要花更多的时间去读懂代码，开发者被阻塞的时间也更长。因此就进入了恶性循环。

相比之下，非阻塞式的代码检视方法会更好一些。
我认为非阻塞检视方法能够解决上面阻塞式检视方法的所有问题。

• 监视者不会阻塞开发者的工作。
• 我会花多10秒来写注释，因为等会会有人会检视。我发现从未被检视过的代码很晦涩难懂，因为没有一种督促让他将代码写的更易读。

另外一种对代码检视的实践方法是结对编程，这个最近似乎很流行但是又似乎实践不起来。

结对编程是阻塞式代码检视方法和非阻塞式代码检视方法的中间态，检视者不会阻塞开发者，因为他们一起开发。
结对编程似乎是代码检视的最佳实践，但是结对编程也有缺点：
假如结对的两个人能力差距很悬殊，则不如非阻塞式，因为能力强的这个人的生产率被能力弱的拉下来了。

对于结对编程看看项目组的具体情况来实施，针对一些核心业务逻辑的代码，可以找两个能力相当且都对业务比较熟悉的开发者来实现，这种效果比较好，在开发代码的同时也做到了代码检视的效果。

总结起来说，代码检视是项目中必须要做一件事情，通常我们推荐非阻塞式代码检视，对于核心业务，建议使用结对编程。

本文链接：https://www.yunweipai.com/622.html