1.只审查正确的东西，让工具干别的

你不需要在代码风格和格式问题上与人争论。有大量的工具可以持续地强调这些内容。确保代码正确、易于理解和可维护性强才是重要的。当然了，编码风格和格式也是这些的一部分，只是你更应该让工具去检查。

2.所有人都该做代码审查

一些人比另一些人更擅长审查。更有经验的人可以发现更多的bug，这很重要。不过更重要的是在总体上维持一个针对代码审查的积极态度，也就是说要避免任何“我们和他们”的对抗态度，或者是让代码审查成为某个人的负担。

3.审查所有的代码

没有代码是因为太短或者太简单而不值得审查。当你审查一切，就没有什么会漏掉。另外这样做会成为流程的一部分，成为一种习惯，而不总是事后诸葛。

4.态度积极

这一点对审查者和提交者都很重要。代码审查不是你要拿全A，发动代码神技的时候，也不是你需要摆出防御姿态的时候。带着对建设性批评的积极态度投入进去，你就可以在此过程中收获信任。

二、写给对审查者的：

5.代码审查应该短期高频

你的审查效率在一个小时后开始下降。所以推迟审查共走，然后在一个极限的周期内赶完对谁也没用。在你的一天中留出时间来定期处理，别打乱自己的工作节奏并养成习惯。你的同事会为此而感谢你。等待会让人沮丧。而且当代码还新鲜的保存在他们脑海里时，他们解决问题也会快一些。

6.It’s OK to say “It’s all good” |“都挺好”挺好

别太挑剔了，你不是一定要每次审查都发现问题。

7.使用一个清单

代码审查清单确保一致性——每个人都了解哪些是重要的，哪些是常见错误。

三、写给代码提交者的

8.保证代码简短

超过200行，审查效率就会显著下降。一旦你超过400行，那基本就没什么意义了。

9.提供上下文

要提供相关的单子，或者规格说明的链接。像Kiln这样的代码审查工具可以提供帮助。应提供简短而有用的提交信息，在代码中留下大量注释。这会帮助审查者，你得到的问题反馈也会少一些。

1.只审查正确的东西，让工具干别的

你不需要在代码风格和格式问题上与人争论。有大量的工具可以持续地强调这些内容。确保代码正确、易于理解和可维护性强才是重要的。当然了，编码风格和格式也是这些的一部分，只是你更应该让工具去检查。

2.所有人都该做代码审查

一些人比另一些人更擅长审查。更有经验的人可以发现更多的bug，这很重要。不过更重要的是在总体上维持一个针对代码审查的积极态度，也就是说要避免任何“我们和他们”的对抗态度，或者是让代码审查成为某个人的负担。

3.审查所有的代码

没有代码是因为太短或者太简单而不值得审查。当你审查一切，就没有什么会漏掉。另外这样做会成为流程的一部分，成为一种习惯，而不总是事后诸葛。

4.态度积极

这一点对审查者和提交者都很重要。代码审查不是你要拿全A，发动代码神技的时候，也不是你需要摆出防御姿态的时候。带着对建设性批评的积极态度投入进去，你就可以在此过程中收获信任。

二、写给对审查者的：

5.代码审查应该短期高频

你的审查效率在一个小时后开始下降。所以推迟审查共走，然后在一个极限的周期内赶完对谁也没用。在你的一天中留出时间来定期处理，别打乱自己的工作节奏并养成习惯。你的同事会为此而感谢你。等待会让人沮丧。而且当代码还新鲜的保存在他们脑海里时，他们解决问题也会快一些。

6.It’s OK to say “It’s all good” |“都挺好”挺好

别太挑剔了，你不是一定要每次审查都发现问题。

7.使用一个清单

代码审查清单确保一致性——每个人都了解哪些是重要的，哪些是常见错误。

三、写给代码提交者的

8.保证代码简短

超过200行，审查效率就会显著下降。一旦你超过400行，那基本就没什么意义了。

9.提供上下文

要提供相关的单子，或者规格说明的链接。像Kiln这样的代码审查工具可以提供帮助。应提供简短而有用的提交信息，在代码中留下大量注释。这会帮助审查者，你得到的问题反馈也会少一些。