在软件开发领域，代码审查看起来是一个少有争议、相当平和的话题。
主流观点普遍认为代码审查是个好东西。有些公司或组织甚至强制要求把代码互审作为必须的流程。
审查是一种捕捉bug和问题的好措施。通过代码审查能够分享领域知识，提高代码质量。代码审查提供了一个对团队进行监控，教育和强化的好机会。
至少理论上是这样的…
当挽起袖子开干，当面对真正的项目计划产生的压力时，代码审查很有可能转而变成一件坏事。
审查是一种能够导致憎恨和分裂的活动。它能使人对编写的代码是否正确产生怀疑，会激起人们为他们自己的编码标准而宣扬说教。代码审查是一种日常活动，它执行的正确与否带来的是团队的开发效率的提升或是扼杀。
对于一个团队，有效的代码审查走的是一条中庸的路线——它既不会成为解决一切问题的银弹，也不会成为伤害团队的毒药。
经过一些思考和跟一些同事讨论之后，我认为，成功的代码审查的关于因素是 信任和训练。
团队成员必须相信，来自代码审查中的反馈意见并不是对个人攻击或对自己能力的评判。审查者必须相信，受审查者不会因为你提出了改进意见而憎恨你。
团队成员必须把代码审核看着是一个能不断得到建设性反馈意见的平台，而不是用来对团队成员评分评级或制造消极激进言论的工具。
当一个团队组成时，信任并不是天生就存在于团队成员中的。
而训练人们如何正确的展开一次代码审查，可以让人们在审查过程中建立信任。
所有我呆过的项目团队中，我发现，学习如何正确的做代码审查的方法就是让大家审查自己的代码。这样之后，你才会知道如何给别人做代码审查！这种方法提供了很多真实情景来解释如何进行代码审查。
训练新手如何正确的提出评审意见，告诉他们应该关注什么才能给有经验的程序员提出有价值的意见。指导团队负责人在合适的时候给予评审者支持，点出有意义的评审意见，这样能强化团队的信任，使团队成员互相尊敬。
那么，代码审查是好事还是坏事呢？
这依赖于你的团队的愿望，是否努力把它变成一种积极的措施。就像对于任何这种开发方法论，简单拿过来用是不行的——你必须保证你在以正确的方式用它。
嗯，这个需要一定程度的团队政治安全保障。在安全受到威胁时，大多数人会选择沉默。
讲到了实质的地方。分析的很到位。
团队应该在一段时间的代码审查之后建立相似的代码美学，团队成员要学会接受多样的正确性。否则很容易产生流派之争，表现形式是一些人对着没有什么问题的代码大肆攻击然后提出另外一种正确的解决方案。
一致的代码美学，这点也不简单啊，特别是对于牛人和“牛人”。绝对的一致可能会抹杀创新。
特别是有一份并不怎么出彩的编码规范，这引起的争议太多了。其实编码规范里有“规则”和“建议”等不同等级，我建议“规则”要少而精，经得起推敲符合软件开发的绝对主流观点，而“建议”则只是对若干个性中的一种进行推荐，审查时只检查规则，“建议”条目建议忽略。
嗨，我们公司的规范要求变量一定要在函数开头定义，这，软件复杂度里有一个准则是计算变量生命期的，这条规范就显的不太合理。
呀，膜拜啊，我曾经翻译过。
如果大家都往积极的方面想，肯定是好处大于弊端的。
这点我想要看审查者和被审查者的情商。
可以适当地在团队中开展代码审查的活动，作为知识传播、团队成员学习的一种有效的方式。真正实施起来，比较难的是让每个参与人员都能很好地集中注意力。