Code Review是目前常用的代码质量保证方法，在这种实践中，写code的程序员要向同伴们展示他的源代码，接受大家的审查，并且解释他的设计思路。
这是一种很好的软件工程实践，也是对软件缺陷预防的一个重要手段。从质量角度，由非作者阅读代码，可以及时发现被作者遗漏过去的问题；从维护角度，可以使更多人掌握代码的实际含义，今后的代码维护也变得容易；从团队建设的角度，可以使team的成员相互学习程序设计思想、方法和技巧；从成本的角度，虽然在review的时候会有较高的cost，但由于是在代码编写阶段进行的，对bug进行预防性的活动，能有效降低集成测试阶段的bug fix的工作量。
但是，没有银弹。
code review本身来说，整个流程非常清晰，逻辑也非常简单，但在执行的过程中，往往不能顺利的取得预期的效果。在某些时候，甚至会蜕变成掩盖问题，甚至产生更多新问题的陷阱。和所有的prcoess一样，code review也要面对具体执行过程中，执行力不足的困难。
困难之一，是进行code review的一个重要条件，即参加review的人员的编码和对系统的了解情况，必须相差不大，处在一个水平线上。在XP Practices中，有一个核心实践pair programming，就要求相互结对的程序员的水平要基本相似，其原因和理由是和review中的情况相似的。如果水平相差过大，就变成了training而不是review了。所谓的审查会议，也只能空耗时间而难有建树。
困难之二，是如何有效保证review的时间，避免因时间问题使其变成走过场，流于形式。考虑到review开始前的准备、一起进行的review会议、即会议后对结果的回顾和检查，每个参加者对每百行代码的时间成本，至少在1小时以上，而一般review的参与者都在三个人以上，从而每百行代码的时间成本，要接近到一个staff day。对于一个两万行核心代码的小型项目来说，code review要占用到八到十个人月的时间成本，对整个项目的schedule来说，是一个影响很大的task项。是否能够在项目初期，就能考虑并保留出这段时间，在项目中期，能顶着schedule的压力，坚持按计划完成review，在项目后期，能有效的分析和回顾review的结果，预防bug的发生，即需要来自上层管理者的肯定，也需要整个team共同的认识。在一个匆忙赶进度，以时间而不是质量为第一目标的开发氛围中，code review非常容易变成一个无效的空壳，成为只为数据服务的形象工程。
困难之三，是如何真正的把握review的目的，以良好的态度来完成。review的参与者可以有两种态度，相互学习肯定对方能力的态度，和相互纠错证明自己能力的态度。在一个真正的开发团队中，大家有着共同的目标，是以第一种心态来进行review工作的；而在大多数缺乏认同感的开发团队中，心态往往就是第二种。从执行和结果上来看，两者都会产同类似的review记录，找到同样多的bug，但将一个松散的团队放在review的聚光灯下，只会引起更多的内耗。而项目的管理者，对review也可以有两种态度，针对review的数据并带领团队改善的态度，和针对review参与者并作为对其绩效考核的态度。在以是否在review过程中找到bug来作为判断参与者绩效和能力的氛围中，也容易时review的参与者开始惧怕面对错误而使review的效果降低。
软件质量不能仅仅依靠测试来保证，必须从项目开始的第一天，就逐步的构建出来。code review是对代码的回顾，是跳出局部的检查，是对bug的预防。克劳士比所说，第一次就要把事情做对！code review就是在“质量预防”的思想下进行的软件工程实践。