何以至此
Neville-Neil并没有详细说明他们的公司为何再三陷入这样的泥潭的，我们可以通过周围发生的事情做出一个猜测。事情的源头是系统中的一部分代码在功能完成之初就缺少必要的注释和文档，更糟糕的是有一些试验性的代码没有清除掉。这部分代码的编写者离开之后，接替者是不愿意修改或者删除不是他们编写的代码。他们的理由是：“我不懂那段代码，我来的时候就已经写好了”。这其实是典型的反模式:Lava Flow(岩浆流)-这些代码刚刚出现的时候还具有可变的本质，但是天长日久就像玄武岩一样坚硬难以去除。这种代码的影响比变量名不规范，面条代码的还要严重。
编译器可以读你的代码但不了解你的意图和设计，于是只有写代码的人懂得那块代码的意图。事实上Neville-Neil的公司就真的高薪聘回那些代码编写者。
而代码审查是可以在源头上将问题解决，问题解决的早晚付出的代价可是真的不一样的。
Why
Neville-Neil指出一个事实:很多人会忽视代码审查,认为代码检查是非生产性的，只是一群人坐在一起了解那些他们不熟悉的代码。
这种观点作者没有给出评价，我认为是对错参半：
- 发现代码问题，找出系统中的Bug，提高软件质量
- 团队中更多的人熟悉代码：这恰恰就是Neville-Neil希望的。
- 代码检查会占用新功能的开发时间，但是将问题尽早的暴露出来
Neville-Neil表示代码审查对于他们来讲有点亡羊补牢,但它依然是危机中项目良好的自救方式。
How
不是所有的开发者都懂得如何进行代码审查,并保证代码审查的效果。
Neville-Neil详细阐述了他对代码审查的从计划、组织到执行，以及如何保证过程有效的种种看法。我们一起来看一下：
从上图看出，他将代码审查分成三个阶段：准备阶段，检查阶段，后续。而每一个阶段都有一些重要的原则来保证过程的有效性。
总结
通过代码审查能够在开发的早些时候发现问题，并规避Lava Flow的出现。代码审查最为人诟病的是占用开发时间，因此良好的准备、安排时间并注重代码审查会议的有效性极为重要。发现问题不是目的，目的是解决问题，代码审查之后的工作落实也要跟踪。建议大家读读George V. Neville-Neil的这篇文章：Kode reviews 101- A review of code review do's and don'ts.
参考资料：
《反模式：危机中的软件、架构和项目重构》
Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills.
源文档 <http://en.wikipedia.org/wiki/Code_review>
