（给
伯乐在线
加星标，看经典文章
）
编译：伯乐在线/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》中写道：
产品的作者与评审者之间的互动至关重要。
作者必须足够信任和尊重评审者才能接受他们的意见。
同样，评审者必须尊重作者的才华和辛勤工作。评审者应谨慎选择他们用来提出问题的词汇，重点关注他们对产品的观察。说『我没有看到这些变量被初始化
』可能会引发建设性的反馈
， 而『你没有初始化这些变量』可能会让作者非常不爽。
关注代码很容易，但不要忘记，桌子（或计算机）的另一端有一个人。他有主见有
“
自我
”
。请记住，解决问题的方式有很多。
-
要谦虚。
我既见过非常高效的评审，也见过因为吹毛求疵而非常低效的评审
。
不要吹毛求疵
！！！
-
确保您有编码标准
。
编码标准是在组织中共享的人人都认同的一套准则。如果你没有编码标准，那么不要让讨论变成一个比较编码风格的比赛（大括号
{
在同一行还是下一行！）如果你遇到这样的情况，请在编码标准论坛上离线讨论
。
-
学会良好地沟通。
你必须能够清楚地表达想法和理由。
-
编程策略是一个仁者见仁智者见智的问题。
评审者和开发人员应该寻求理解彼此的观点，而不应该成为哲学辩论
