《Peer Reviews in Software: A Practical Guide》第2章 - (1)

 

让别人指出工作中的错误是需要学习的，并不是天生就会的。我们都自豪于自己的工作，从不乐于承认错误。我们不知道犯了多少错，也不愿意其他人发现这些错误。如果你正着手于建立成功的Peer Review,这些自然的抵触情绪就必须克服。

Peer Review是和技术训练类似的社交活动。在一个组织中，逐步灌输Review流程，一定要了解组织文化和成员们所持有的价值观。经理们应当相信花在Review的时间是一种投次，然后为团队安排Review,你要理解为什么某些人并不愿意将自己的工作拿给同事们做详细的审查，而且牢骚不断。你也要向团队和经理说明Peer Review流程，期待的行为，以及大家的帮助对于个人和团队的帮助。

互相挠挠后背

比较忙的同事有时并不乐意花时间去看同事的工作。你可能觉得对方是个滑头。他是不是没有自信？他是不是想让你替他思考？抗拒Review的同事可能这样嘲笑说“任何需要对代码进行Review的程序员都不配领工资！”

在一个健康的软件工程文化中，组员们吸引同僚们来共同改善工作质量和生产力。这个一个等价交互的过程，他们在Review别人工作时所花费的时间，会在别人Review自己的工作获得回报。我所知道的那些很棒的程序员都会主动的选择评审人员。相对而主，众多的评审意见会让他们做得更好，特别是那些超出个人能力的部分。

1971年出版(1998再版)的<<The Psychology of Computer Programming>>,作者Gerald Weinberg介绍了"无我式编程"，它阐述了一个事实：人们自我束缚在对自己工作的自负感觉之中。让别人发现自己制造出来的一个缺陷，会让你觉得这是作为一个程序员的自尊心受到了伤害，甚至是伤害了作为一个人的自尊。为了保护自己，你不希望知道你所犯的错，甚至在为可能的Bug在找借口。

如此强的自我保护是有效进行Peer Review的典型障碍，导致一种在团队项目中单打独斗的态度，也必须产出低质的产品。无我式编程主张作者退后，由其他人指出他的作品有哪些地方需要改进。在这种模式下，程序员也充分懂得应当让他们的作品便于他人理解。反之，有些程序员乐于撰写自己才懂的那些晦涩、聪明的代码。这种观念会让所有度图理解这些代码的人倍受困扰。重视无我式编程的经理，会促成团队中的协作气氛，共享成就，并在团队中开放地交流知识技能。

注意这个术语是“无我式编程”，而不是“无我式程序员”。每个人都有权保护自己，开发者需要足够健康的自多意识来相信和守护他们的工作，不然，他们就会拒绝更好的建议。(译注:因为不能确定其可行性)

软件行业的专家们自豪于他们创造性的工作，尽管如此，他们也认识到人总会犯错，同时可以从外部的视角收获许多。无我式的Review者会同情他的同事，除非有特别的理由，不然他们会进行一天的角色转换，认真对待Review。

Review和团队文化

当独立的程序员可以经常从Peer Review中收获时，一个常态化的Review流程只能在重视质量的文化中获得成功。将Review视为开发活动的程序员会帮助个人及团队取得成功，他们理解Review决不是为了发现差劲的开发者，也不是为质量问题找出替罪羊。

Review也可能导致两种不良的态度。有些人开始变得懒散，因为有其他人会帮他发现问题。(译注:责任的猴子) 这就像程序员期望测试人员找到他们的错误一样。事实上，作者需要对他的作品负最终责任。Review只是帮助作者创建高质量成果的一种辅助手段。有时，当我读我所写的草稿时，我常常会听到一个小声音，告诉我有一段不对或语法不合适。我有时告诉自己:"我应该拿给审阅者，看看他们怎么认为"。问题是那些阅稿者总是不喜欢那些拙劣的章节。现在，当我听到这个声音时，我就会主动加以修正，而不去浪费审阅人员的时间。

另一个极度需要避免的是一种追求完美的诱惑，在送出Review前努力将作品做得完美。这是一种自我保护的策略：你不用为那些别人没看到的失误感到尴尬。我曾经带过一个工程师，她绝不在作品完成前，或者她认为足够好之前，拿给别人进行Review。她所有的事基本都做了：完整的实现、测试、按标准格式代码，还有文档。她将Review视为一种接收式认证，而不是实际意义上的开发流程中的一项质量改善活动。