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

　　这里有几点事实：

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

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

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

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

　　我发现赞成阻塞式检视方法的人，通常会觉得太多自由是导致代码质量差的原因。有一种观点是：如果检视者不带着一种强烈的责任感去检视代码，那么检视者就会松懈然后检视就完成不了。

　　首先，我的经验告诉我，这个观点是不正确的。我发现在使用非阻塞方法的项目中，检视者也非常努力的检视，通常在少于一周的时间完成检视任务。

　　不过，不管观点的支持方还是反对方，都存在一个固有的缺陷：我们没有认识到阻塞式检视和非阻塞式检视都式依赖你的团队（或者项目的检视规则）。

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

　　我们可以汇总阻塞式检视的问题：

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

　　● 等待检视完成的过程中，开发者被阻塞了，什么事情也干不了。

　　● 开发者会一次尽可能提交多的代码，因为他们不想经常被阻塞，经常被中断。

　　● 代码太多了会给检视者带来问题，他们要花更多的时间去读懂代码，开发者被阻塞的时间也更长。因此就进入了恶性循环。

　　相比之下，非阻塞式的代码检视方法会更好一些。

　　我认为非阻塞检视方法能够解决上面阻塞式检视方法的所有问题。

　　● 监视者不会阻塞开发者的工作。

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

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

　　结对编程是阻塞式代码检视方法和非阻塞式代码检视方法的中间态，检视者不会阻塞开发者，因为他们一起开发。

　　结对编程似乎是代码检视的最佳实践，但是结对编程也有缺点：

　　假如结对的两个人能力差距很悬殊，则不如非阻塞式，因为能力强的这个人的生产率被能力弱的拉下来了。

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

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