作为程序员，及早的发现问题，很快的知道自己该干什么是一个很好的习惯，但是程序员必须要遵守这几个原则，今天小编通过赛比尔电脑培训学校为大家整理了一些资料，希望对大家有所帮助。

永远别忘了TDD

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

尽可能的自动化

  这里有几个非常好的Java工具比如：PMD,Checkstyle,Findbugs等等。问题是当利用这些工具查找后人们还肯花时间去做代码审查吗？
  使用这些工具前，为这些工具制定一套细则是非常重要的。这能够确保你使用同一个代码审核标准从而区别于那些常被用于20世纪老式的代码审查规范。在理想的状态下，这些工具可运行在各种版本控制系统上通过hook审查每个代码。如果该代码不好将被阻止在外。

尊重设计

  在我开始从事Java项目早期时，用代码审查的方式已为时已晚。因为当你检查代码问题时实际上给你的设计造成了缺陷。设计模式被误解，一些繁杂的附属物质混入进来或者开发者脱离了主题。
  审查会混乱你的观点。或许你会反驳：“这是代码审查而不是设计审查”。这时一些烂摊子必然会接踵而至。为了避免这些问题发生，我们改变了设计的初衷。代码审查会牵连到很多面，无论是设计还是设计审查。事实上，我们通过设计审查要比代码审而得多的冲击要多的多。设计需要更高的质量和灵感，我们应该避免一些复杂的思维。

统一的风格指南

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

挑选适宜的工具

  如果开发者都在使用Eclipse开发工具（Eclipse IDE插件Jupiter），你可以通过你的方式来查看代码、调试代码甚至可使用Eclipse IDE上的一切东西当来帮助你在审查代码时更加的便捷。但是，如果大家没有使用同一个IDE（或者该IDE没有给你的*带来方便）你可以考虑Review Board.，它是个不错的选择。

请记住每个项目都不同

  也许你在采用以前的项目方法*，但是，请记住每个项目之间是不同的。每一个项目都有特定的架构（高并发或是高分散），有特定的文化（或许很多人喜欢使用Eclipse），并使用特定的工具（maven or ant）。难道你想照葫芦画瓢？OK，请记住，不同的项目有不同的*方法。