review,在项目开发中应该不陌生吧。尤其在对日开发的项目里,几乎所有的成果(文档,代码)都要经历这一步才能判断是否完成。
比如一个项目里有一年开发经验的小张和有5年开发经验的大刘两个人。不去管他们两个的职位的高低,由大刘去review小张的工作应该是理所当然的吧。
但是,这样的安排有一个问题,那就是review的结果受个人的因素所制约。
比如,如果还有一个有10年开发经验的老王的话,那么大刘review通过的文档,在老王看起来也许还存在不少问题。这个是经验能力上的差异造成的。
再有,还会受个人性格差异的影响。一个大大咧咧的人和一个仔细认真的人review的结果肯定不会一样。这也就产生的不公平,对工作的评价也会受到影响。
从项目的角度讲,因为无法统一review的标准,从而影响产品的质量。
从个人的角度将,review的结果就像是碰运气:碰到好说话的人,可能很顺利的通过;碰到严格的人,则反复的修改,影响自己的绩效考核。对团队合作也不会有什么益处。
我想到的解决方法,就是颠倒顺序,由经验少的人去review经验多的人。
菜鸟review高手,让小张去review大刘和老王的工作。这听起来好像很荒谬:连人家写的是什么意思都搞不明白呢,还review个什么劲啊!?
这可能要先搞清楚review的定义吧。我自己的定义是,review是检查一个工作是否符合事先确定下来的规范。
简单的说,review是判断对错,而不是判断好坏。(这部分的内容我也许会随后继续讨论,如果大家有兴趣的话。。。)
而判断好坏很难,因人而异,没有正解。但是判断对错很容易。但是这需要有一个前提,那就是有规范以及检查是否符合规范的手段。
比如一个工厂里面生产铁块,规范是3×4×5(厘米)。而检验员则会用尺子来量铁块是否符合规范。这个几乎谁都可以做,不需要经验。而3×4×5这个规范是好是坏,则不是检验员需要考虑的。
软件开发的项目里,也要从这个角度来考虑,定义出不受人为控制的规范和检测手段。那么自然,review这个动作由菜鸟来做也没什么问题,而检查是根据规范来走的,对检查结果也很难有什么争议。
这样,有经验的开发人员可以集中精力在开发上,而不需要经常的review别人的工作。review人员也可以从中学到开发时需要注意的问题,为以后自己参与开发时打好基础。(这一点其实很重要,因为他们知道检查的内容,以后自己参与开发是自然会加以注意)
当然,定义这种规范并不是轻松的事情,而且也不可能完美。只是一个理想的目标,至于能达到什么程度,则因公司、项目、预算而异了。
我也只是有感而发,想起什么写什么。大家有什么建议,欢迎讨论。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/378235/viewspace-696323/
,如需转载,请注明出处,否则将追究法律责任。