导读：良好的代码审查工作不仅可以培养团队合作精神，还能帮助开发人员成长，并且提高软件开发质量。

我被提升为高级开发工程师，而且代码审查（Code Review）也成为我职责的一部分。但是我意识到自己的经历还没有让我做好站在那一边的准备。

每次我被要求做代码审查时，我会变得胆怯，感觉自己像个冒名顶替者。有很多个问题折磨着我：

• 我应该点评这行代码吗？

• 我认为有更好的方法来编写这个类。但我应该告诉他吗？

• 这个人怎么会这么想？他比我更有工作经验。

• 更改此代码会让程序崩溃吗？

• 我的导师建议我时，会怎么样？

其实，良好的代码审查侧重于各种可能性的结果，而不是单向关注，去寻找代码的Bug。开发者不要将评审视为审讯，而是让代码审查规则变成可以改进代码风格、寻找替代解决方案、增加学习和共享所有权等优势为指导。

作为审阅者，你在代码评审中的反馈是建立渴望贡献的开发者社区的主要方式之一。通过培养强大的社区，你将不断推广优质产品、优秀团队和优质生活。

以下是进行良好代码审查的一些观点和建议。

1. 设定目标并获取指标

Scott M. Graffius 说：

“如果你不设定任何指标，那就是在盲目飞行。但是如果你收集和关注太多，它们可能会挡住你的视野。”

关键平衡是人们收集指标的方式。太多的指标会浪费时间，没有指标就像在没有舵的船在漫无目的的航行。在实施流程之前，你的团队应该决定如何衡量代码审查的有效性并列出具体目标。

根据工程师们的经验，良好的代码应该具备如下特点：

1）功能第一——它应该按预期工作

2）整洁并可维护——可读性要高

3）优化良好——在生产环境中按预期执行

我们定义的指标应该有目标，以确保在审查期间和审查之后进行测量和跟踪改进。

例如：

“将客户支持电话减少 15%”，或者 “在开发过程中将缺陷率降低 50%”。

请记住，目标应该让你对代码的改进情况有量化的了解。“修复更多Bug”并不一定会增加任何价值。

爱因斯坦恰当地告诉我们：

科学管理、强化测量和分析是首个真实的管理原则。

2.批评思维，而不是个人

Frank A. Clark 说：

“批评就像小雨，它应该是温和的，能滋润人的成长而不去毁坏人的根系。”

为什么代码审查讨论，有时会失控并变得情绪化？

当我们停止讨论一个想法的优点，开始讨论创造该想法的人时，就会发生这种情况。我们总是很容易说，“你这个，你怎么这么傻，你为什么不能实现并发的代码。” 

实际上，你需要优雅、冷静和成熟说：

“我很好奇你是如何实现这段代码的。这段代码将如何处理并发？”

两句话区别很明显。在第一种对话中，你似乎在羞辱一个人，并给他子弹来进行一场开放式的辩论。但是在第二种方法中，你只讨论代码，没有评判，没有指责，只是简单的澄清。

请记住，加入少量的礼貌用语对与此人进行有意义的对话大有裨益，这样可确保专注于一个想法的纯粹优点，不要被部落仇杀和个人偏见所消耗。

保持你的专业，而不是针对个人。

3.提问直到你理解

库布拉赛特说：

“提出问题是开始改变的首要方式。”

如果你不熟悉该应用软件，你也无法进行良好的代码审查，就是如此简单。

你需要查看认为相关联的内容，不要管其他人的想法。这要求你在每一步都更加深入、提出问题并确认你的理解。

你就像一个正在治疗病人的医生。身为医生会问病人各种问题——他的习惯、饮食、压力水平、正在服用的药物等等。然后医生会提出改进建议，而人体是一个复杂的引擎，如果医生不坚持不懈的望闻问切，那他将无法找到问题的根源。

因此，代码审查也应该遵循同样的原则。

自由软件开发者 Nigel Munoz 鼓励代码审阅者思考“这种变化如何影响更大和更小的图景。” 大局考虑包括查找任何重复的、非模块化的或不遵守标准规约的代码，包括分析对代码架构的修改。

不要只接受工程师表面上告诉自己的内容。不断的发问，直到你对代码的了如指掌，就和开发人员的知识一样。

4. 不要用小勺喂食

迈蒙尼德说：

“给一个人一条鱼，他只能吃一天；授人以渔，可养其一生。”

当你在做 Code Review 的时候，你也在扮演导师的角色，好的导师教书，而不是填鸭。

这种方法的几大目标，我们列表如下：

1）让代码审查成为学习和分享的交流会议；

2）开发人员拥有代码的完全所有权，而不能依赖你帮助他们解决问题。

3）我正在创造和培养下一波有才华的高级开发人员。

一旦整个团队都采用这种学习态度，你很快就会发现团队内部的智力资本正在上升。

同时，这样也可以发展开发人员的健康自我。这种“自我效应”会激励开发者编写更简洁的代码，因为这让他们有机会展示自己吸收的知识，并为此感到充满自豪的成就感。

5. 最后，审查代码不要超过 60 分钟

加里·卡斯帕罗夫 (Garry Kasparov) 说得好：

“连续几天努力工作而不失去注意力的能力，是一种天赋。经过几个小时学习，能够不断吸收新信息的能力也是一种天赋。”

不要让代码审查成为苦差事的代名词。如果你吸收知识的能力每过一分钟都在下降，那意味着你需要休息一下，休整之后再让你的思维重新发挥全部的能力。

最好的方法，在较短的时间会议中进行代码评审。不要一次审查太多行代码，这样不太可能发现缺陷。

经常进行审查不仅可以改进团队代码库质量，还可以让你确定每个问题的最佳解决方案，而不是只想到问题的第一种解决方案。

最后，请让代码审查成为一件积极和充满乐趣的事情。

我们要赞扬这样一个事实，就是进入产品来报告Bug，这会导致客户不满意。谁或哪些人怎样引入Bug并不重要。唯一重要的是你和团队在创造更好的产品方面在发挥着重要作用，并以此为荣才是关键之处。

培养这种积极的技术文化，会大大有助于代码审查成为一种协作的、成员拥有的活动，在这种活动里，团队会欣赏，而不是害怕代码审查。

正如海伦凯勒所说：

“一个人能做的事情很少；一群人可以一起做很多事情。”

作者：场长