如果您真面临着搜索错误(bug)的烦恼，那么请确认您已经将它们全部安装了!

　　既然您已经学会了代码评审流程 的佳实践方式，那么我们接下来将会讨论一些社会效应，以及怎样管理它们以获得佳的结果。

　　8. 培养良好的代码评审文化氛围，在这样的氛围中可以积极地评审缺陷

　　与其他我们能看到的大多数技术相比，代码评审对于真实团队构建能够发挥更大的作用，但是只是在管理人员能够以一种积极的，向上的，有技巧的方式进行交流时，这种优势才能发挥出来。将缺陷看做是不好的事物很容易(毕竟，它们是代码之中的错误(bug))，但是形成不好的缺陷检查态度，则会毁掉整个团队的努力，更不要说它会破坏错误(bug)检查过程了。

　　软件代码评审的要点在于，尽可能多的消除缺陷，不管是谁“导致”了错误(bug)。

　　管理人员必须建立缺陷是积极的这样的观点。毕竟，每一个缺陷的存在，都是改进代码的潜在机会，而错误(bug)评审过程的目的，在于使代码尽可能地完美。每一个被发现并解决的缺陷，都是客户以后不会看到的缺陷，也是 QA 人员不必花费时间去解决的问题。

　　团队需要维持这样一种态度，是发现缺陷，意味着代码开发者和评审者作为一个团队去改进产品的质量成功了。而不是“代码开发者产生了一个缺陷，而评审者负责去发现它”。它更像是结对编程的一种有效形式。

　　评审员要向所有的开发者展示收集坏习惯，学习新技巧，并展开功能的机会。开发人员可以从他们的错误(bug)中学习，但是只是在他们警惕错误(bug)时才会这样。如果开发人员害怕发现错误(bug)，那么积极的结果会消失。

　　如果您是一名初级开发人员，或者是一个团队的新成员，那么其他人发现缺陷时，意味着您强有力的队友在帮助您成长为一个合格的开发员。这比您单枪匹马地编程，没有具体的反馈时，要更快地进步。

　　为了维持检查缺陷是积极的这样一种理念，管理人员必须要承诺缺陷密度不会进入到性能报告之中。公开作出这种承诺是很有效的。这样开发员会知道他们要怎样做，并抗议公开破坏这条规则的管理人员。

　　管理人员绝不应该将错误(bug)代码作为消极性能评审的基础。他们必须谨慎对待，并对批评造成的挫折感及消极反应保持敏感，并要一直提醒团队发现错误(bug)是一件很好的事情。

　　9. 警惕老大哥效应(Big Brother Effect)

　　作为一个开发人员，您可以自动假设“老大哥正看着您呢”是真的，如果评审制度是由评审支持工具自动评价的，更是这样的。您是否花费了很长的时间去评审一下更改?您的同行从您的代码中是否发现了很多错误(bug)?这将如何影响您下一步的性能评价?

　　评估报表不应用来对付开发人员，尤其是在面对结对评审员时。这一做法会严重破坏道德观。

　　制度对于流程评价来说非常重要，这反过来，又为流程改进提供了一个基础。但是制度也可以被用来做坏事。如果开发人员相信制度是用来对付他们的，那么他们不光是对流程有敌意，而且他们的注意力可能转到改变制度，而不是编写更好的代码，和变得更有效率上。

　　管理人员可以做很多事情，来解决这个问题。首先也是重要的，他们必须要警惕这一点，并且必须确定代码开发者没有面临很多的压力，而“老大哥”问题必须每次都得到详细的检查。

　　制度应该用来评价流程的效率，或者流程更改的效果。记住，通常来说，困难的代码是由有经验的开发人员处理的。这些代码，反过来，有可能出问题，因此难检查，也有可能发现多的缺陷。因此，大量的缺陷很有可能是由复杂性，以及代码的分块性造成的，而不是代码开发者的能力造成的。

　　如果制度确实能够帮助一个管理人员去发现一个问题，那么将某人踢出局可能会产生更多的问题。我们推荐管理人员在解决相关问题时，要将一个小组当做整体来对待。所以好不要召开专门的会议，因为开发人员在解决特定的问题可能会有压力。相反，您可以通过一个每周状态会议，或者正常的程序来解决问题。

　　管理人员必须不断地维持这样一个年头，即搜索缺陷是好的事情，而不是糟糕的，缺陷密度与开发员的能力并不是挂钩的。记住对一个团队来说，缺陷，尤其是团队成员所引入缺陷的数量不应该被回避，也不应该用作能力的评价参数。

　　10. 评审一部分的代码，算您不能全部完成，以从自我效能感(Ego Effect)中获益

　　想象一下您自己坐在编译器的前面，任务是需要修复一个小小的错误(bug)。但是您知道只要您说出了“我完成了”，您的同行 — 或者更糟，您的老板 — 要检查您的工作了。这会改变您的开发个性吗?所以在您工作时，一般是在您声明代码评审完成之前，会更加的谨慎了。如此您立即会成为一个更好的开发人员了，因为在您背后别人议论您时会说，“他的员工非常谨慎，他真是一个不错的开发人员”;而不是“他犯了大量愚蠢的错误(bug)。当他说工作完成时，实际上还差着远呢”。

　　自我效能感(Ego Effect)会促使开发人员编写更好的代码，因为他们知道其他人将会查看自己编写的代码及作品。没有人想被其他人认为自己经常犯初级的错误(bug)。Ego Effect 促使开发人员在向其他人交付作品时更加谨慎地进行评审。

　　Ego Effect 的一个良好特征，是不管评审者要对所有的代码变更负责，还是仅仅执行“点检查”，像随机性的药物测试一样，都能正常地发挥作用。如果您的代码有三分之一的几率被评审者抽中进行评审，那么它仍然足以刺激评审者谨慎工作。如果您只有十分之一的概率被抽中检查，那么可能您不会如此勤奋了。您知道您会说，“哈，我很少犯错”。

　　评审 20%~33% 的代码时，从 Ego Effect 中获得花费时间方面的收益可能大，评审 20% 的代码肯定要比不评审强很多。

　　11. 采用轻量级，工具支持的代码评审

　　代码评审一般有些主要的类型和无数的变数，而指南却能适用它们中的任何一个。但是，为了完全优化团队花在评审之上的时间，我们要使用工具支持的轻量级评审过程来得到优的结果。搜索缺席时，它是有效的，实用的。