9.不要做"房间里的人"。
不要成为在黑暗处 编码只为买可乐的人。房间里的人和外界失去了联系，看不见外面，并且失控，他没有 开放 、协作的工作环境。
10.请注意审查会议不是解决问题的会议。
11.有助于维护编码标准。
提供要添加到编码标准中的东西，这些事我们讨论时编码标准中没有的东西。挑战之一，开发人员已经 组织比较 麻烦的代码审查工作 ，他们往往不知道接下来的问题将从哪里来。如果你把每个问题的文档编写标准，下次你的 代码审查你可以 用清单检查它 。它还会帮到你巩固你已经掌握的概念，让您更不容易错过反馈的机会 。
7.世界上唯一不变的就是变化。
敞开心扉 ，并微笑着接受它。 留心对 您的需求、平台或工具都作为新的挑战 的 每一个变化，不至于最后严重到 不可收拾的地步 。
8.为你的信念而战，但从容地接受失败。
要明白，有时候你的想法会被推翻，即使你被证明是正确的，不被报复或者数落，"我告诉过你了"这句话至少在 好几次 以上，并且不让你离开的想法滋生。
8.骄傲/奖励。对他编码能力的认可对许多程序员来说，是一个显著的奖励。
9.团队凝聚力。一起工作可以让团队成员变得更加紧密。它还可以让因为写代码而造成的隔离得到一个短暂的释放 。
代码审查者所关注的地方主要有以下几点： 通用的单元测试 注释和编码规范 错误处理 资源泄漏 线程安全 控制结构 性能 功能 安全
5.无论你知道的"karate"有多么的多，其他人也总是会知道的更多。
如果你问，这样的人员可以教你一些新举措。寻求和接受别人的意见，特别是当你觉得不需要的时候。
6.未经咨询讨论，不重写代码。
”重写代码“和”修改代码“只是一步之遥，知道差异、追求在代码审查的框架内 的风格变化，不要一个人孤独 的奋战 。
10. 不要草草地进行代码审核，但需要及时的。
你的同伴正在等你审核！
11. 一次审核200-400行代码。
代码审查结果的指定严重程度
代码中发现的问题的严重程度应该如下所示。审查者必须首先聚焦高级严重程度的问题，然后是中级严重程度的 问题，最后是低级严重程度的问题。
1. 命名规则和代码风格=低级 2. 控制结构或逻辑问题=中级 3. 冗余问题=高级 4. 性能问题=高级 5. 安全问题=高级 6. 可测量性问题=高级 7. 功能性问题=高级 8. 错误处理=高级 9. 可重用性问题=中级
3.你和你的代码不等同。
记得整个评审的目的是为了发现问题，并且问题是一定会被发现的。有人发现了你的问题，千万不要介意啊。
4.要理解并接受你所犯的错误。
评审的目的是尽早的发现问题，避免将问题带到以后的产品中去。幸运的是，除了在JPL我们几个开发rocket guidance software，我们的行业很少有致命的错误，所以我们可以，我们应该学会笑，然后继续。
6. 避免使用“为什么”。
尽管很难避免，但如此而为能够充分地改善气氛。正如肯定句刺耳一样，“为什么”也如同一把尖刀。大多数的 “为什么”能够经过变过而被省略，并达到激动人心的效果。例如，“你为什么没有遵循标准？”->”出于何处 原因在这里对标准做了一些变化？”
7. 记得要赞美。
审核代码的目的不仅仅是告诉开发人员如果提高，同样也要告诉他们做得好。人类的本性就是想要被认可，不要 仅仅体现出我们的过错。因为开发是一项创造性的工作，开发人员用”心“在写代码，所以这更需要赞美，即使 更多的批判。
给审查者的提示
1. 批评代码而不是人。
体贴开发者而不是代码。尽可能的使用正面、积极的，并且有利于提高代码质量的评价。评价要与项目标准、开 发守则、性能提升等因素相关。
2. 尊重了员时，通常认为恃才傲物的比较牛逼，自卑的比较烂。不要用愤怒与焦躁来增强这样的 陈规旧习。
对开发人员的提示
1.最初的评审者应该是作者自己。 2.为自己的评审的代码更趋于关注的东西创建清单。 这些清单中有些是很容易收集整理的。它应该遵循编码标准文档的大纲，因为这是你的评审清单，即便是有问题 ，你可以抓住你很难做的东西，并且跳过你认为很简单的东西。按照你列出来的清单往下测试你的代码，并修改
你发现的问题。这样你不仅仅是减少了团队其他人发现的问题，而且也减少了评审会议的时间，大家都会非常高 兴能够使用很短的时间开评审会议。
3. 真正的权威来源于学识，而不是地位。
学识造就权威、权威带来尊重。
4. 注意！审核代码的会议并不意味着解决问题的会议。
5. 使用疑问句而不是肯定句。
肯定句是刺耳的。“在这里，你并没有遵循标准”，这样的话语就是一种攻击，无论你是否有意而为之。“是什 么原因促使你使用现在的方法？”会得到更多的信息。很显然，这样的问题无法以一种讽刺或是傲慢的语气来表 述；但这样做是正确的，如此的对话会让开发人员开始思考，继而寻找更好的方法。
8. 确保你有良好的编码规范作为参考。
审核者遵循的依据应当是组织的编码规范。编码规范是一份被开发人员普遍认可的协议，用于编写优质的代码。 如果要讨论一项并不在代码规范中的代码，你首先要做的工作是建立相关的代码规范。你应该不断地询问自己是 否在讨论编码规范中的事项。
9. 条条大路通罗马。
尽管开发者使用的方法与你想象的大相径庭，但不一定是错的。审核代码的目标是代码质量。如果达到了目标并 遵循了标准，这就是你想要的。
6.大家对代码有一个平均的理解，这有助于提高团队成员的互换性，特别当某个成员无法继续工作的时候就显得尤 为重要。
7.从不同的角度看问题。“另外一双眼睛”增加了客观性。这个原因也是把开发和测试团队分开的原因，同行评审 代码发现问题需要提供给他们一定的距离（译者注：这个距离可以使他们和代码的作者从不同的角度看问题）。
代码审查
代码评审就是源代码的系统性审核（也叫同业互查），目的是找到并且修复在开发最初阶段被忽视掉的一些问题 ，以此来改进软件质量，同时提高程序员的编码能力。
代码评审为什么重要呢？
代码审查的主要目标有： 1.尽早的发现和修复代码中的缺陷。 2.以更好的共享和理解代码作为团队成员相互学习的基础。 3.有助于保持设计和实现的一致性。 4.帮助发现大家容易犯的共同错误，从而减少团队的返工。 5.构建投资者对执行过程中技术质量的信心。