到底应该是谁review谁？

    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博客 ” ，链接：http://blog.itpub.net/378235/viewspace-696323/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/378235/viewspace-696323/