有句老话说：“不要谈论宗教或政治”。
为什么？
因为这些主题充满了强烈的见解，但客观答案却很薄弱。
一个人的确定性就是另一个人的怀疑。
别人的常识只是对那些持不同看法的人
的先验偏见。
可悲的是，与这些有争议的主题进行对话会产生比光更多的热量。
人们常常会伤透脑筋，以至于他们忘记了“ 讨论 ”的结果与他们的预期寿命，薪水，赢得x因子的机会，获得梦想的日期，赢得彩票，寻找机会无关。应对气候变化或他们认为重要的一切！
同样，在软件工程世界中，代码审查可能最终导致毫无意义的冲突。 开发人员可以为愚蠢的小事情争吵，互相冒犯，并且偶尔会捕获到一个可能会在质量检查中发现的错误-即将发生冲突的自由区域 ！
现在不要误会我的意思，有完全正当的理由使您可能认为代码审查对您的项目是个好主意：
- 尽早发现错误意味着项目成本降低。 您不必发布修补程序补丁，因为它已处于开发阶段– yippee！
- 代码变得更加可维护。 Jonny用宿醉编写的那种疯狂的200行方法已经被抓住，然后才有机会让自己深入到您的代码库中。
- 知识遍布您的团队。 不再只有一个人知道的大型代码块。 众所周知，当一个人谈论休假两个月时，每个人都会感到恐慌！
- 开发人员付出了更多的努力。 如果开发人员知道其他人将对他的工作做出判断，那么他更有可能使用该行Javadoc来澄清何时将引发异常。
但是，认为代码审查不会引起问题会很天真。
实际上，它们引起了很多21世纪项目无法解决的问题。
我认为它们占有一席之地，但是需要对如何以及何时完成这些方法进行一些思考，以使它们有益而不是麻烦。
这是一些指导原则...
在要求他人查看代码之前，请确保已测试了代码。
赶上您自己的错误并在其他人之前处理它们。
有几种非常好的Java工具，例如
PMD ，
Checkstyle ，
Findbugs等，当这些工具可以非常快速地识别出人们会浪费时间抱怨的许多事情时，让人们花时间审查代码
又有什么意义呢？
我要再说一遍。
当这些工具可以非常Swift地识别出很多人会浪费时间抱怨的事情时，让人们花时间检查代码又有什么意义呢？
使用这些工具时，对它们使用一组通用规则很重要。
这样可以确保您的代码符合某种商定的标准，并且不需要发生在20世纪老式代码审查中曾经发生的大部分事情。
理想情况下，应通过版本控制系统中的钩子在每次代码检入时运行这些工具。
如果代码真的很糟糕–它将被阻止检入。Billy阻止开发人员检入他写的垃圾（当他有致命的偏头痛时），因为他太尴尬而无法查看。
实际上，您正在帮他，而不只是您的团队。
在一些早期的Java项目，我的工作的，评论的方式发生为时已晚。
当实际设计存在缺陷时，您正在查看代码。
一种设计模式被误解了，引入了一些讨厌的依赖关系，或者开发人员走得很远。
审查将提出这些观点。
众所周知的反驳是：“ 这是代码审查，而不是设计审查！”
。
随之而来的是一团糟。
为了解决这些问题，我们进行了一些更改，以便要求审查代码的任何人（以某种方式）也将参与设计或设计审查。
实际上，与代码审查相比，我们从设计审查中获得的收益更大。
设计的质量要高得多，后来那些令人讨厌的惊喜停止了。
即使使用自动化工具（例如Checkstyle，Findbugs等），也要避免样式上不必要的冲突，您的项目应具有样式指南。
尽可能遵循行业标准的Java约定。
尝试为您的项目引入的所有概念写一本“字典”。
这意味着，当代码引用它们时，更容易检查用法和上下文是否正确。
如果您所有的开发人员都在使用Eclipse（并且乐于使用它），那么Jupiter之类的东西就有意义。 您可以在代码中进行导航，调试代码，并实质上利用Eclipse IDE所做的一切来使您在查看代码时更轻松地看代码。 但是，如果每个人都不在同一个IDE上（或者IDE不能使您的生活变得更轻松），请考虑使用诸如Review Board之类的东西。
您可能在上一个可行的项目中做了一些工作。 但是请记住，每个项目都是不同的。 另一个项目具有特定的体系结构（可能是高度并发，高度分散的），具有特定的文化（每个人都可能喜欢使用Eclipse），并使用了某些工具（ maven或ant ）。 新的一个是否打勾相同的框？ 请记住，不同的项目适用于不同的项目。
复习阳性时，要一丝不苟，但不要学究。
琐碎的琐碎事情会使项目失败或使公司损失金钱吗？
可能不是。
透视事物。
记住要对其他想法持开放态度，并且要改变自己的想法，而不是因改变别人的想法而挂断电话。
根据我的经验，我称之为“伙伴审查 ”（别人称之为“ 过肩”）已经工作非常出色。
伙伴审核包括每天或每两天与另一位团队成员非正式会面，并在您的办公桌或他们的办公桌旁快速浏览（5 – 10分钟）彼此的代码。
这种方法意味着：
- 问题很早就被发现
- 您始终掌握最新情况
- 审查总是很短，因为自从上次赶上以来您只在看新代码
- 因为环境是非正式的-没有紧张感。 他们很好玩！
- 您可以定期交流思想。
当技术负责人时，伙伴检查您的团队成员是查看团队中有人是否早早陷入麻烦的好方法。
您可以同时帮助他人并了解每个人的进度。
并且由于好友评论的定期性质，它们变得习惯并且实际上完成了。
对于其他许多21世纪代码评论，我们不能说！
总而言之，如果您的项目要进行代码审查，那么它们应该快速，有效并且不要浪费时间。 正如本文所讨论的，考虑如何组织它们以确保不会发生是非常重要的 。
'直到下一次–照顾好自己。
参考：我们的JCG合作伙伴 Alex Staveley在都柏林技术博客上 的21世纪代码审查 。
