11项针对轻量级高效同行代码评审-2
上一篇 / 下一篇 2012-08-23 09:38:28 / 个人分类:杂谈
&g6~@?jw']G*R0 团队需要维持这样一种态度,就是发现缺陷,就意味着代码开发者和评审者 作为一个团队 去改进产品的质量成功了。而不是“代码开发者产生了一个缺陷,而评审者负责去发现它”。它更像是配对编程的一种有效形式。51Testing软件测试网*do.c N-I*\
51Testing软件测试网&|{KfLi%KiWln评审员要向所有的开发者展示收集坏习惯,学习新技巧,并展开功能的机会。开发员可以从他们的错误(bug)中学习,但是只是在他们警惕错误(bug)时才会这样。如果开发员害怕发现错误(bug),那么积极的结果就会消失。51Testing软件测试网2@%I0_gH
51Testing软件测试网$Y gy4V4Qg| w!F0V8j如果您是一名初级开发员,或者是一个团队的新成员,那么其他人发现缺陷时,就意味着您强有力的队友在帮助您成长为一个合格的开发员。这就比您单枪匹马地编程,没有具体的反馈时,要更快地进步。51Testing软件测试网+R]8wD4w[O
51Testing软件测试网~LZ$X d4h`mF^为了维持检查缺陷是积极的这样一种理念,管理人员必须要承诺缺陷密度不会进入到性能报告之中。公开作出这种承诺是很有效的。这样开发员就会知道他们要怎样做,并抗议公开破坏这条规则的管理人员。
6sF)pq"E_H,Ey_2Z,g&_-K0%yWgkwY:i0 管理人员绝不应该将错误(bug)代码作为消极性能评审的基础。他们必须谨慎对待,并对批评造成的挫折感及消极反应保持敏感,并要一直提醒团队发现错误(bug)是一件很好的事情。51Testing软件测试网 i{vP-z
51Testing软件测试网#KL0Ru(C|+OZ8[9、警惕老大哥效应(Big Brother Effect)51Testing软件测试网/fi(p!^*r {+eZJ1@
j4SUb2v-CT#\0 作为一个开发员,您可以自动假设“老大哥正看着您呢”是真的,如果评审制度是由评审支持工具自动评价的,更是这样的。您是否花费了很长的时间去评审一下更改?您的同行从您的代码中是否发现了很多错误(bug)?这将如何影响您下一步的性能评价?51Testing软件测试网,rl1sdJ;y` s^a
51Testing软件测试网q0_9k2l8kU4Qjh t"y-g4R评估报表不应用来对付开发人员,尤其是在面对结对评审员时。这一做法会严重破坏道德观。
\6Sx l5Nb051Testing软件测试网q7y|.b'`2Q G制度对于流程评价来说非常重要,这反过来,又为流程改进提供了一个基础。但是制度也可以被用来做坏事。如果开发员相信制度是用来对付他们的,那么他们不光是对流程有敌意,而且他们的注意力可能转到改变制度,而不是编写更好的代码,和变得更有效率上。51Testing软件测试网AdUP8xL(_o J
51Testing软件测试网dc7Tz1{"s!D!B管理员可以做很多事情,来解决这个问题。首先也是最重要的,他们必须要警惕这一点,并且必须确定代码开发者没有面临很多的压力,而“老大哥”问题必须每次都得到详细的检查。
X:d p'PvFL9{,g0R4R Xs,S?0 制度应该用来评价流程的效率,或者流程更改的效果。记住,通常来说,最困难的代码是由最有经验的开发员处理的。这些代码,反过来,最有可能出问 题,因此最难检查,也有可能发现最多的缺陷。因此,大量的缺陷很有可能是由复杂性,以及代码的分块性造成的,而不是代码开发者的能力造成的。
)A Z3`e%V Ni.`$e051Testing软件测试网.FV+jVKv如果制度确实能够帮助一个管理员去发现一个问题,那么将某人踢出局可能会产生更多的问题。我们推荐管理员在解决相关问题时,要将一个小组当做整 体来对待。所以最好不要召开专门的会议,因为开发员在解决特定的问题可能会有压力。相反,您可以通过一个每周状态会议,或者正常的程序来解决问题。51Testing软件测试网-jH,dus&I
51Testing软件测试网%w?8IN8L.F'O管理员必须不断地维持这样一个年头,即搜索缺陷是好的事情,而不是糟糕的,缺陷密度与开发员的能力并不是挂钩的。记住对一个团队来说,缺陷,尤其是团队成员所引入缺陷的数量不应该被回避,也不应该用作能力的评价参数。51Testing软件测试网(`w|+i Y H w$X
51Testing软件测试网Ai\:Ez;e"jD9T10、评审一部分的代码,就算您不能全部完成,以从自我效能感(Ego Effect)中获益
|@7G GN2eW~0Zn${h/u6s*Gb|0 想象一下您自己坐在编译器的前面,任务是需要修复一个小小的错误(bug)。但是您知道只要您说出了“我完成了”,您的同行 — 或者更糟,您的老板 — 就要检查您的工作了。这会改变您的开发个性吗?所以在您工作时,一般是在您声明代码评审完成之前,就会更加的谨慎了。如此您立即就会成为一个更好的开发员 了,因为在您背后别人议论您时就会说,“他的员工非常谨慎,他真是一个不错的开发员”;而不是“他犯了大量愚蠢的错误(bug)。当他说工作完成时,实际 上还差着远呢”。
l Mai A"B#K)}!Ix+y0:]I0B| ~9V0 自我效能感(Ego Effect)会促使开发员编写更好的代码,因为他们知道其他人将会查看自己编写的代码及作品。没有人想被其他人认为自己经常犯初级的错误(bug)。Ego Effect 促使开发员在向其他人交付作品时更加谨慎地进行评审。51Testing软件测试网.~ P(F(H#}
Jl,|Dz0 Ego Effect 的一个良好特征,是不管评审者要对所有的代码变更负责,还是仅仅执行“点检查”,就像随机性的药物测试一样,都能正常地发挥作用。如果您的代码有三分之一 的几率被评审者抽中进行评审,那么它仍然足以刺激评审者谨慎工作。如果您只有十分之一的概率被抽中检查,那么可能您就不会如此勤奋了。您知道您会说, “哈,我很少犯错”。51Testing软件测试网*xP$e0H6y
)Tfu#[%z`c"IuA9g(a&h0 评审 20–33% 的代码时,从 Ego Effect 中获得花费时间方面的收益可能最大,评审 20% 的代码肯定要比不评审强很多。
;YX'T5y4i1Eo0H2X RT]&q#|}:t'^0 11、采用轻量级,工具支持的代码评审
6_f3_bf\C:_'u/f4^x00B*N,D7FQ3q;[0 代码评审一般有些主要的类型和无数的变数,而指南却能适用它们中的任何一个。但是,为了完全优化团队花在评审之上的时间,我们要使用工具支持的轻量级评审过程来得到最优的结果。搜索缺席时,它是有效的,实用的。51Testing软件测试网&\}dK-C Rw