以前做国内项目时，并没有做代码评审的概念。最早接触到代码评审，还是接触到极限编程的时候，当时大家对其中那个结对编程的实践很感兴趣，这一实践说在编码的同时也就完成了代码评审，当时大家并没有领会其中深刻的含义，只是觉得从成本的角度来说，任何一个老板都不能容忍这种情况的出现：两个人同时在编一个程序。

后来做国外项目时才发现人家代码评审的要求很严格，我们每次编完的代码，都要发过去，人家一行一行看，觉得不符合要求的地方都记录下来发给我们，我们再按照记录修改直到最后人家同意放行代码，这才能进入测试阶段。这样一看，结队编程的实践基本就不存在成本的问题，反而是一种将编程与评审并行的实践方法，两个人同时在做两件事。

不过这个实践跟重流程的那些方法有一个重要的区别，这也是敏捷方法与重流程方法的主要区别，这种方式的代码评审能留下的记录很少，敏捷方法本身就是轻文档的。虽然说代码里面有黄金，不过合适的文档里面也是无限宝藏啊。所以那些重文档的流程依旧要求文档，但是它们也对如何只书写有价值的文档做了很慎重的考虑，看起来就是受了敏捷方法的启发。

我们在进行公司的质量体系认证的时候，咨询公司就对我们进行代码评审留下的记录这一点做了简化处理，评审一定要有，但是评审记录并不要求那么严格。我们的理解是跟项目的质量目标有关。拿6西格玛打比方，你要达到3西格玛的质量目标的话，你没必要付出6西格玛需要的成本。但是反过来如果你的质量目标是6西格玛的话，那你无论如何也不能按照3西格玛的要求来做。