1.先确定 code review 的目标优先级

在 code review 之前先和你的团队成员明确 code review 中事项的优先级。

作者认为 code review 中应该做的事：

• 熟悉同事在编程时的思考方式，这样其余同事以后如果有需要就可以更轻松、快速的修改代码。
• 向同事介绍修改了哪些文件，增加了什么样的功能，这样在问题出现时，可以保证至少有两个人可以帮助诊断、解决问题。

不建议在 code review 中做的事：

• 找 bug。自动化测试、运行程序要比几个人坐着看代码有效率多了。
• 检查代码规范。现在的 IDE 和编辑器都有自动规范代码的工具，为什么还要在这方面浪费人力呢？

2.把程序跑起来

读其实是一种很不自然的和代码交互的方式。仅仅靠读代码来找 bug 效率实在不能算高，要知道计算机能比你的大脑更好地运行代码。

把程序运行起来，亲自试一试，或许你会有一些和他们测试时不同的操作，发现一些他们遗漏的问题。

并且现在的 IDE 中断点调试，都能够很详细的显示运行时的程序数据，这能帮助你更容易的理解这段代码是如何运行的。

3.明确方法的调用层次

作者发现很多人谈起 code review 的第一印象就是一堆人坐在一个电脑面前一行一行的看代码。但这么做其实效率是很低的，除非你的经验非常丰富，否则真的不建议就靠一双眼睛和你的大脑来做 code review。用工具明确方法的调用层次，能帮助你更有效的梳理代码逻辑。

4.尽可能及时的进行 code review

当你收到别人的 code review 邀请时，尽量第一时间就开始。因为这时作者的记忆是最清晰的，并且通常会对你的及时反馈心怀感激，这种正面情绪对于 code review 是非常有帮助的。

如果你觉得自己在面对 code review 时有困难的话，作者在这里推荐了两个方法：

• 事先设置一个时限，比如半小时。也就是在你的第一次 review 中，先花半个小时理解变动的代码，写下自己的问题。如果在这个时间范围内，你不能确定代码变动是否没有问题，把你的想法和问题先发给作者，之后再确定一个时间进一步的 review。
• 在你的机器上保留两个独立的仓库。一个用于你自己的修改，另一个用于 review。这样你和作者之间的修改就能够保持彼此独立。

5.在你读代码之前，先想想自己会怎么做

先读一下功能说明，思考下如果是自己来可能会怎么做，之后再查看作者实际做出的修改。如果有和你想得不一样的地方，就可以和作者进行交流，讨论清楚为什么。这样做能使得你们两个都得到成长，还能提高 code review 的效率。

6.在实际的开发环境中 review

现在的 code review 早就不是光用眼睛看啦，各种强大的 IDE 完全可以成为我们的一大助力。善用 IDE 的力量。

7.不要吝啬你的赞扬，除非你能证明那里确实有一个 bug

每个人的内心深处都是期待被别人称赞的，因此在 code review 开始的时候不要老是揪着变量命名、代码重复之类的问题。先集中注意力在真正重要的地方，给作者一个舒服、放松的心态（通常刚开始 code review 的时候作者是会很紧张的）。这样他们也就会乐于接受你对于代码风格等方面的建议了。: )