导读：代码审查已经被广泛的认可为一种非常好的做法，现在很多大公司比如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协议的规范标准。尝试着为你的项目介绍制定一个“词典”，这就意味着，当涉及这个代码时，查看该代码的用法和环境是否适宜，这些都很容易被检测出。
5. 挑选适宜的工具
如果开发者都在使用Eclipse开发工具（ Eclipse IDE插件Jupiter），你可以通过你的方式来查看代码、调试代码甚至可使用Eclipse IDE上的一切东西当来帮助你在审查代码时更加的便捷。但是，如果大家没有使用同一个IDE（或者该IDE没有给你的工作带来方便）你可以考虑Review Board. ，它是个不错的选择。
6.请记住每个项目都不同
也许你在采用以前的项目方法工作，但是，请记住每个项目之间是不同的。每一个项目都有特定的架构（高并发或是高分散），有特定的文化（或许很多人喜欢使用Eclipse），并使用特定的工具（maven or ant）。难道你想照葫芦画瓢？OK，请记住，不同的项目有不同的工作方法。
7.懂得取舍
代码审查需要积极和细致而不是卖弄学问。你会因为一些细微的琐事让你紧张而导致项目失败或是花费公司成本吗？记住，千万不要这样。理清头绪，换个角度想想，改变自己的心态而不是记挂着去改变别人。
8. Be buddies
在我看来，称之为“buddy reviews”（别人会叫“over the shoulder”）非常好。A buddy review是指与其他团队成员每隔一到两天以非正式的形式讨论，并且快速的浏览（5-10分钟）对方的代码。这种方法可以帮助你：
1. 及早的发现问题
2. 总是很快的知道该干什么
3. 代码审查无须过长，因为你只需要查看新的代码，旧的代码会很快赶上
4. 这种非正式的场合——没有紧张感，很有趣！
5. 可以定期的交换想法
buddy reviewing在团队中是一种很好的工作方式，当某人在团队中出现问题时可以及早的发现。这不仅可以帮助大家，还可以交换彼此的进度和想法。
总之，如果你的项目正在进行代码审查，应该做到快速、有效、不浪费别人的时间。正如文章所说的，这几点非常重要。代码审查用意是在代码提交前找到其中的问题。
（注：本文由夏梦竹编译，转载请注明出处）
75
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
