代码静态测试:高效同行代码评审最佳实践(3)

　　如果您真面临着搜索错误(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. 采用轻量级，工具支持的代码评审

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

原文转自：http://www.ltesting.net