代码review是一个工程师去检查另一个工程师所写的代码是否有缺陷和可改进空间的过程。换言之，开发者自己写代码，而当代码写好后，会叫上另一位工程帮助审查，这就是代码的review。
代码review已经被证明是加强软件质量的可靠的方法。在Google，所有的代码都会被结对审查。从代码大全（第二版）引用一些例子：
IBM的Orbit项目有500000行代码使用了11个级别检查。它交付及时并且达到了普遍意义上的期望值，大约只有1%的错误
AT&T的一个部门做过一个研究，有超过200人说，引入代码的review后，开发效率提高了14%，同时减少了90%的错误。
Jet Propulsion Laboratories估计，在开发阶段早期引入代码的review，每次检查并修复缺陷可以节约$25000
但是，很多团队仍然对代码review的作用表示了质疑，他们表示并未收到很多益处。在一些内部有问题的团队和组织，这件事情迅速就让所有涉及到的人感到混乱不堪，比如以下这些事：
1 代码review变成了某些爱炫技的同事的一个秀场，他们指出别人代码里无关痛痒的“问题”，然后抛出他们自己看似高大上实际上没毛用的观点，以表现自己的牛逼（译者：请原谅我的粗口，遇到过不少这样的人）
2 开发者变得很保守，他们不等到代码完全确认无误，不愿意让其他人来审查----这确实有可能是件好事情，但是这也有可能会错过代码审查的最佳时机。
3 开发者不想再对自己的代码负责，他们完全依赖于别人来帮助找出错误
基于这些问题，我想聊一聊团队和组织能做哪些事情，可以让每个参与到代码的审查工作的成员，都会觉得舒服一点。
给管理团队的建议：营造正确的公司文化
高效的代码审查要求公司有健康的文化，价值观上就是为了追求产品的质量和卓越。如果一个团队都不坚信他们是要去做出高质量的产品，代码的审查确实不会给他们带来期望的结果。你需要去营造积极的文化氛围，每一个员工都执着于去提出建设性的意见，同时能够允许那些最好的点子被采纳。
除了营造优秀的公司文化，以及给review工作分配足够的时间和资源以外，最好不要有太多的管理层人员参与。这是一种文化，大多数人都不希望在老板面前暴露自己有可能比较“脏乱差”的代码。代码审查工作最好是有程序员的搭档在主持，管理者最好不要插手那些细节，过去甚至以此来评判员工----没错，一些经理会去查看那些问题的清单，然后还去给员工打分，以便他们能以此去考核自己的员工的工作能力。
可能你的公司已经有了很好的公司文化（算你走狗屎运了）。也有可能你正在改善中。正确的文化有赖于很多因素。这是巨大的挑战，而且没有魔术一般的公式。脱离了正确的公司文化，代码审查这项工作往往会事与愿违，产生副作用!
写给每个人的：你是在和人打交道
在 Peer Reviews in Software: A Practical Guide一书中，Wiegers写到：
产品作者和审查员之间的互动关系是非常关键的。作者必须详细和尊重审查员并寄予他们建议足够的尊重。类似的，审查员也必须对作者的能力和勤奋工作寄予充分的尊重。审查员在指出问题时，应该对措辞深思熟虑，将注意力集中在产品本身。说“我没想看到这些变量初始化的位置”就可能收到积极的回应，相比说“你没有初始化这些变量”有可能会使作者极其不爽。
代码是很容易就稳定下来的，但是请记住，坐在另一张桌子或是电脑后面的一定是人。是人就一定会有自己的观点。人是一种很自负的生物。记住解决问题的方式有很多：
1 谦逊一些。我见过卓有成效的审查员，也见过产生了巨大负作用的审查员，后者老是像个刺头；
2 确定你遵守了编码规范。编码规范是由集思广益的产物。如果你没有按规范编码，那么就不用老是拿着自己的编码风格和人去争辩。如果你进入这么一个状态，那么最好还是在会后再去讨论你的编码风格问题。
3 学会沟通。你必须要能清晰的表达自己的观点和原因。
4 编码其实和你看问题的角度有关。审查员和开发者都应该致力于明白对方的观点，而不是去讨论一些哲学问题（作者的观点是, 代码怎么写都行，不要老是试图用自己的做事逻辑去评判别人）
给审查员的建议：低调谦逊一点
1 开发者都不是好惹的。记住，审查的目的不是为了炫耀谁是更好的程序员：它是为了找出缺陷，同时也是为了让代码更简单和可维护。
2 多使用询问的句式。不要让你的要求或者是陈述听上去像找事的。举个例子，不要说：“你没有遵循原则XYZ”。一个更好的方式，是先试着真诚的去了解开发者这么设计的初衷：“你是怎么理解原则XYZ，如果把他们应用到这里是不是合适呢?” 这样的询问，可以让你方便的引入讨论下一个观点。
3 千万不要使用“你为什么不” “你为什么不”这样的句式。这样问话会让人产生防备心。“为什么你使用了这个全局变量？”，你可以试着换个句式，比如“我不太明白这里为什么要使用一个全局变量。”代码审查的一个很重要的目的就是要写出可维护性的代码。
4 一定要多去欣赏和感谢其他人。说话的人，经常会忘了，其实“这活儿真牛逼”和“这活儿看上去还不错”差别还蛮大的。
如果你使用这些方法时，给人的感觉特别的刻意或者听上去有点嘲讽的口吻，就起不来多大的作用了。把代码审查看成是一个普通的谈话。你一定要多倾听，并且真诚的去的了解他们的目的。有必要的情况下，再给出你的建议。如果代码写得很好，千万不要没事找事。
给开发者的建议：不要夹带太多的个人风格
1 不要有私人情绪在里边。记住要找出的反派是代码里的缺陷和不足，不是要找你的茬。
2 认清一个普遍的情况，很可能你写的代码会成为你个人的标签（译者注：码农一定要珍惜自己的羽毛）。如果你以你的工作为傲，那么这是一件好事，因为你是那种很在乎技术水平的人。
3 有自信是好事，但千万别自负。你要相信自己的想法是正确的，但千万不要不加思考的拒绝别人的想法和建议；
4 记住，是人就会犯错。审查者是作为另一双眼睛也许可以帮你发现你可能忽视掉的事情。问题本身就是有价值的建议。
5 多问一些具体细节的问题。“把所有的类都挪到他们自己的包里，这样做是否真的有意义？”
6 感谢审查者们的时间和反馈
小结
结对审查是和另一个人的互动，如果交流上有问题，那就起到什么作用了。但是经理们花了很多时间去担心应该使用哪个有用的工具--如果工具真是有用，也不是工具本身就能起到立竿见影的作用。开始建立好的团队文化....也请记住人性。