首先必须承认Code Review的价值。经验丰富的专家们在做代码审查的时候，能够根据以往经验，规避重大缺陷的发生，对开发人员给予有价值的指导。然而，这个过程，太冗长，太低效。
Code Review必须基于事实。这里的事实，就是，源代码库。SVN Repository, 或者HG/Git Repository. 在多人协作环境中，对于一份不在源代码库代码是基本不可信的 —— 你无法预知，他是否将会成为最终可工作软件的一部分。
积攒下来众多的代码修改，使得产生重型、低效的沟通方式成为必然。这类众型的沟通方式往往成本惊人 – 需要占用最好的人很长时间。
过分夸大专家的作用。根据以往经验，许多最终发现问题，回溯上来，其实是一些简单的逻辑问题。这些问题如果分散在平时结对或者更频繁的过程中，则更容易发现。很多情况下，是开发人员对常见的bad smell了解和修炼不足，而这些bad smell常常是导致问题的地方。例如在一个已经有3重循环的方法中加入了新的判断而没有测试；修改了函数的返回值而没有任何说明；if 判断中包含了多达4-5个变量的比较判断而没有抽象为一个更具业务含义的方法，等等。Review手段的原始落后。
Review必须基于变化。会看报表的人都知道，看报表只需要看两个东西：趋势和拐点。Code Review也一样，只需要看变化。SVN/Hg/Git这类现代化的工具给我们提供了丰富的，基于changeset的compare工具。查看一天，整个团队的check in情况，顶多只需要10分钟-15分钟。
在敏捷过程中，Code Review几乎是一个被忽视的环节——不是不做，而是时时在做。结对时，我们会对结对伙伴的编码习惯、新写的类、变量表示质疑；提交之后，有代码静态检查工具、单元测试工具、覆盖率工具帮助我们检查有没有犯简单愚蠢的错误、有没有破坏既有功能；持续集成服务器则中立、不知疲倦的在每次我们提交之后运行所有的过程。
Code Review不是一个审查环节。不是一个考核环节。它是交流和反馈环节。