导读：代码审查已经被广泛的认可为一种非常好的做法，现在很多大公司比如Google也在做代码审查。代码审查不仅可以有助于你的工作，还能分享知识。原文是《Code reviews in the 21st Century》，现对此文进行编译。文章内容如下：

　　在软件工程领域里代码审查可以结束程序员之间无谓的争执。开发者常常会因为一些愚蠢的小事斗嘴，冒犯对方，甚至是在Q&A问答之前抓住Bug而喋喋不休，争执总是围绕在你左右。OK，千万不要误会我的意思，因为我们有理由相信代码审查绝对是个不错的好方法。原因如下：

　　（1）越早发现bug也就意味着可降低项目成本。无须释放一个修复补丁，因为它正处在开发阶段。

　　（2）代码变得越来越重要。

　　（3）知识贯穿于你的团队中，不再像以前那样一大块代码只有某一个人知道。

　　（4）开发者需要加倍的努力。如果开发者知道别人要对他的工作进行评估时，就会采取额外的努力做好工作，同时他还喜欢用文档注释标出异议。

　　如今，在21世纪的今天很多项目都没有使用代码审查。本文将提供8条准则，供开发者学习与参考。

　　1、永远别忘了TDD

　　再确认测试代码前，先找别人帮你检查下是否无误。在别人做之前尽量检查出bug并且将其处理好。代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。

　　2、尽可能的自动化

　　这里有几个非常好的Java工具比如：PMD， Checkstyle， Findbugs等等。问题是当利用这些工具查找后人们还肯花时间去做代码审查吗？

　　使用这些工具前，为这些工具制定一套细则是非常重要的。这能够确保你使用同一个代码审核标准从而区别于那些常被用于20世纪老式的代码审查规范。在理想的状态下，这些工具可运行在各种版本控制系统上通过hook审查每个代码。如果该代码不好将被阻止在外。

　　3、尊重设计

　　在我开始从事Java项目早期时，用代码审查的方式已为时已晚。因为当你检查代码问题时实际上给你的设计造成了缺陷。设计模式被误解，一些繁杂的附属物质混入进来或者开发者脱离了主题。

　　审查会混乱你的观点。或许你会反驳：“这是代码审查而不是设计审查”。这时一些烂摊子必然会接踵而至。为了避免这些问题发生，我们改变了设计的初衷。代码审查会牵连到很多面，无论是设计还是设计审查。事实上，我们通过设计审查要比代码审而得多的冲击要多的多。设计需要更高的质量和灵感，我们应该避免一些复杂的思维。

　　4、统一的风格指南

　　即使是使用自动化工具（诸如Checkstyle，Findbugs等）也应避免不必要的风格冲突，你的项目应该具备有风格指南。（在尽可能的情况下）坚持Java协议的规范标准。尝试着为你的项目介绍制定一个“词典”，这就意味着，当涉及这个代码时，查看该代码的用法和环境是否适宜，这些都很容易被检测出。