（点击
上方公众号
，可快速关注）
编译：伯乐在线/maifans
如有好文章
投稿，请点击 → 这里了解详情
代码评审（Code review）是保证代码质量的一种有效手段，做得好的话，对公司来讲是一笔收益颇高的时间投资。但实践起来往往变成了炫耀编程技能、固执己见、恶言相向、同事关系恶化的事，这该如何是好？
往往代码评审过程中，评审者（Reviewer）往往会过于关心旁枝末节，而忽视主要问题，也就是所谓的自行车棚效应。在批准价值百亿的核电站的建设提案中，专家们往往会浪费大量时间纠结于厂内自行车棚（bikeshed）的颜色；因为核电站太大、太复杂，“专家们”未必真懂，但总不能不说话啊，那就从无关痛痒的自行车棚挑毛病吧。
有效的代码评审
代码评审是开发人员编写的代码由另一个人检查以查找缺陷和改进的过程。换句话说，开发人员大部分都是独立编写代码的，当代码完成之后，他们会召集一次评审。
代码评审是提高软件质量的有效途径。在Google，所有代码都要经过同行评审。引用《代码大全（第2版）》中的几个例子：
-
IBM 的 Orbit 项目有 50 万行代码，使用了 11 级的检查。它提前交付，并且只有通常预期错误的百分之一。
-
一份对 AT＆T 的一个 200 多人组织的研究报告显示，在引入评审后，生产率提高了14％，缺陷减少了90％。
-
喷气推进实验室估计，通过早期发现和修复缺陷，每次评审节省约 25,000 美元。
然而，不少团队在有效的代码评审争论中，失去了原本的效益。在功能失调的团队和组织中，对所有参与者来说它可以迅速变成一个
令人不快的经历
：
在这篇文章中，我将讨论团队和组织可以做的一些事情，让代码评审为所有参与者带来愉快的体验。
对管理层的建议：营造健康文化
有效的代码评审，需要一个重视质量和卓越的健康文化。
如果团队不以提供高质量的产品为信仰，代码评审将不会给您所期望的结果。你需要一个人人参与的积极文化—立足于建设性批评，智者胜。
除了创造一个健康文化，并允许花时间和资源进行评审，管理者在代码评审中应保持低姿态。
大多数人不想在上司面前暴露自己的秘密，这已是一种文化。代码评审最好由同行进行，管理层不应该询问可以用来评价人的细节
。
的确有一些管理人员索要检查表和成绩，以便他们可以
“
衡量
”
并评价人。
可能你已经有一个健康的文化（算你幸运）。
这还不够，营造健康的文化取决于许多因素（团队和组织内部）。这是非常具有挑战性的，没有灵丹妙药。没有正确的文化，代码评审不会带来期望的收获，甚至在极端情况下可能会适得其反。
对个人的建议：换位思考
Karl Wiegers 在他的《Peer Reviews in Software: A Practical Guide》中写道：
产品的作者与评审者之间的互动至关重要。
作者必须足够信任和尊重评审者才能接受他们的意见。
