代码审查除了显而易见的对源码本身正确性以及可维护性等方面的验证，交流和学习也应该是其目的之一。和白盒测试相比，在很大程度上有共通之处，但侧重点不同。代码审查更偏重整体性，而白盒测试更偏重局部性。
代码审查一般基于3种目的，包括审查代码风格，审查正确性以及是否与设计相符，还有特定目的的审查，比如效率、容错性、安全性等等。对于我们来说，对于不同部分的代码，可能有不同的目的，有时候甚至多种目的结合起来审查。但是不论如何，每次代码审查都应该确定目的，有的放矢，否则可能很难控制时间和质量。
形式上应该是多样的，针对审查对象，应该有自查，互查，小组走读等各种方式以区别对待，否则可能难以发现隐藏较深的问题，或者因大量的讨论和会议丧失效率。但是如何区别就成了一个问题，对我们来说，什么样的问题才需要小组走读，由谁来判断，如何判断是需要明确的。
代码审查的资源消耗是非常大的，这取决于审查的形式，审查的目的（涉及深度和广度），以及审查的频率。要认识到成本收益比和边际收益递减的规律，当然我们目前审查不足，增加审查力度的边际收益应该还是比较大的。还有一个问题就是过程成本，或者说管理成本，如何保证审查的有效性以及缩减组织审查造成的资源损耗，制度化、规范化应该是一个办法。
审查人员的素质也是关键的。不是说任何人都能成为审查人员，他必须在对象问题上具有一定的权威性，否则审查错误比不审查还要糟糕。而我们目前的情况是，所有具有一定资质的人员，都肩负着管理任务，大多数时间都消耗在公共、行政或者其它事务上，造成在审查力度上的不足，如何协调也是我们需要解决的一个问题。
最后的一点是期望收益的问题。如果我们希望审查发现所有问题，或者实行对审查人员的问责制，可能会造成大家都不愿意去审查代码。审查只是一个保证手段，就好像测试一样。如果一旦发现问题，就责怪审查人员为什么没有发现，那是不可取的。