代码审查：好事？坏事？
在软件开发领域，代码审查看起来是一个少有争议、相当平和的话题。
主流观点普遍认为代码审查是个好东西。有些公司或组织甚至强制要求把代码互审作为必须的流程。
审查是一种捕捉bug和问题的好措施。通过代码审查能够分享领域知识，提高代码质量。代码审查提供了一个对团队进行监控，教育和强化的好机会。
至少理论上是这样的…
当挽起袖子开干，当面对真正的项目计划产生的压力时，代码审查很有可能转而变成一件坏事。
审查是一种能够导致憎恨和分裂的活动。它能使人对编写的代码是否正确产生怀疑，会激起人们为他们自己的编码标准而宣扬说教。代码审查是一种日常活动，它执行的正确与否带来的是团队的开发效率的提升或是扼杀。
对于一个团队，有效的代码审查走的是一条中庸的路线——它既不会成为解决一切问题的银弹，也不会成为伤害团队的毒药。
经过一些思考和跟一些同事讨论之后，我认为，成功的代码审查的关于因素是 信任和训练。
团队成员必须相信，来自代码审查中的反馈意见并不是对个人攻击或对自己能力的评判。审查者必须相信，受审查者不会因为你提出了改进意见而憎恨你。
团队成员必须把代码审核看着是一个能不断得到建设性反馈意见的平台，而不是用来对团队成员评分评级或制造消极激进言论的工具。
当一个团队组成时，信任并不是天生就存在于团队成员中的。
而训练人们如何正确的展开一次代码审查，可以让人们在审查过程中建立信任。
所有我呆过的项目团队中，我发现，学习如何正确的做代码审查的方法就是让大家审查自己的代码。这样之后，你才会知道如何给别人做代码审查！这种方法提供了很多真实情景来解释如何进行代码审查。
训练新手如何正确的提出评审意见，告诉他们应该关注什么才能给有经验的程序员提出有价值的意见。指导团队负责人在合适的时候给予评审者支持，点出有意义的评审意见，这样能强化团队的信任，使团队成员互相尊敬。
那么，代码审查是好事还是坏事呢？
这依赖于你的团队的愿望，是否努力把它变成一种积极的措施。就像对于任何这种开发方法论，简单拿过来用是不行的——你必须保证你在以正确的方式用它。