代码审查（Code Review)是软件开发中经常使用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还能够帮助团队成员提升编程技能，统一编程风格等。
**1. 代码审查要求团队有良好的文化**
团队须要认识到代码审查是为了提升整个团队的能力，而不是针对个体设置的检查“关卡”。
“A的代码有个bug被B发现，因此A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协做，所以须要避免。
另外，代码审查自己能够提升开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。若是开发者对这个流程有抵触或者反感，这个目的就达不到。
**2. 谨慎的使用审查中问题的发现率做为考评标准**
码审查中若是发现问题，对于问题的发现者来讲这是好事，应该予以鼓励。但对于被发现者，咱们不主张使用这个方式予以惩罚。软件开发中bug在所不免，过分苛求自己有悖常理。更糟的是，若是形成参与者怕承担责任，不肯意在审查中指出问题，代码审查就没有任何的价值和意义。
**3. 控制每次审查的代码数量**
根据smartbear在思科所做的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会降低，具体的比例关系以下图所示
（我想这是根据实现状况而定，如结合文档来评审，那么代码多一点也不要紧）
咱们在实践中发现，随着开发平台和开发语言的不一样，最优的代码审查量有所不一样。可是限制每次审查的数量确实很是必要，由于这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，天然不会有太多的产出。
**4. 带着问题去进行审查**
咱们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，而后经过审查工做验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否可以正确工做。
使用这个技巧，可让审查者有代入感，真正的沉浸入代码中，提升效率。你们都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，缘由就是武侠小说更容易产生代入感。
有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在咱们的实践中显得很机械和流程化，不如上面的方法效果好。
**5. 全部的问题和修改，必须由原做者进行确认**
若是在审查中发现问题，务必由原做者进行确认。
这样作有两个目的：
(1)确认问题确实存在，保证问题被解决
(2)让原做者了解问题和不足，帮助其成长
有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构全部代码，但这样不利于提升团队效率，而且会增长由于重构引入新bug的概率，一般状况下咱们不予鼓励。
**6.利用代码审查激活个体“能动性"**
即便项目进度比较紧张，没法彻底的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。
背后的逻辑是，软件开发是很是有创造性的工做，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码均可能被其余人阅读和审察，能够促使开发者集中注意力，尤为是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提升代码质量。
**7.在非正式，轻松的环境下进行代码审查**
如前所述，代码审查是一个脑力密集型的工做。参与者须要在比较轻松的环境下进行该工做。所以，咱们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并很差，不只由于长时间的会议容易让效率低下，更由于会议上可能出现的争议和思考不利于进行如此复杂的工做。
**8.提交代码前自我审查，添加对代码的说明**
全部团队成员在提交代码给其余成员审查前，必须先进行一次审查。此次自我修正形式的审查除了检查代码的正确性之外，还能够完成以下的工做：
(1)对代码添加注释，说明本次修改背后的缘由，方便其余人进行审查。
(2)修正编码风格，尤为是一些关键数据结构和方法的命名，提升代码的可读性。
(3)从全局审视设计，是否完整的考虑了全部情景。在实现以前作的设计若是存在考虑不周的状况，这个阶段能够很好的进行补救。
咱们在实践中发现，即便只有原做者进行代码审查，仍然能够很好的提升代码质量。
**9.实现中记录笔记能够很好的提升问题发现率**
成员在编码的时候应作随手记录，包括在代码中用注释的方式表示，或者记录简单的我的文档，这样作有几个好处：
(1)避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。
(2)根据研究，每一个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，能够在审查的时候用做检查的依据。
(3)在反复记录笔记并在审查中发现相似的问题后，该类问题出现率会显著降低
**10. 使用好的工具进行轻量级的代码审查**
“工欲善其事，必先利其器”。咱们使用的是bitbucket提供的代码托管服务。
每一个团队成员独立开发功能，而后利用Pull Request的形式将代码提交给审查者。复审者能够很方便在网页上阅读代码，添加评论等，而后原做者会自动收到邮件提醒，对审阅的意见进行讨论。
即便团队成员分布在天南海北，利用bitbucket提供的工具也能很好的进行代码审查。
程序员
Google的代码之因此优秀缘由其实很简单：他们很是重视代码审查。代码审查并非Google独有的，它被公认为是一个很好的（提升代码质量的）手段，不少人已经在平常开发中采用代码审查。但我尚未看到哪一家大公司（像Google这样）应用得如此普遍。在 Google，任何的产品或者项目代码在检入（代码仓库）以前都须要进行有效的审查。数据库
每一个人都要参与代码审查，并且这里我指的不是非正式的审查：它是软件开发环节中很是重要并且通用的规则。不只是产品代码，全部的代码都须要进行审查。审查代码不须要投入不少的精力，可是（与不作审查相比）产生的效果倒是天壤之别。编程
关于代码审查（code review），Jonathan Danylko 的见解是“代码要常常检查（包括自查和其余同事检查）。不要把别人的检查，当作是对代码风格的苛求。应该把它们看做是有建设性的批评。对我的来讲，常常检查你的代码而且自问，“我怎样才能写得更好呢？” 这会加速你的成长，让你成为一个更优秀的程序员。”设计模式
**你能从代码审查中收获什么？**浏览器
事实显而易见，有另一我的检查即将提交的代码，可以帮助找到bug。这是代码审查众所周知且常常被说起的好处。但依据个人经验，这是最没有价值的一个好处。人们确实能够在代码审查中找到bug。然而坦率地说，在代码审查中找到的bug绝大多数都是一些代码做者花上几分钟就能找到的小bug。那些真正须要花时间才能找到的bug在代码审查中是检查不到的。缓存
代码审查最大的好处在于它是一种社交的途径。若是你编程的时候就知道会有同事检查你的代码，那么你的程序会有所不一样。你写的代码会更加整洁，有着较好的注释，结构也组织的不错——由于你知道会有人来检查你的代码，并且你很在乎他们的意见。若是没有代码审查，你知道代码会在最后才会审查。由于不是立刻就要检查，因此对你而言并不紧迫，于是你不会想着先自检一遍。安全
代码审查还有一个更大的好处，就是能够分享知识。在不少的开发团队中，每一个人都会负责而且专一于一个核心模块。除非别的同事负责的模块出现问题致使本身的代码不能运行，不然他们是不会去关注别人的工做。这样产生的结果是，每个模块的代码只有一我的比较熟悉。假如事不凑巧，那位程序员正好休假或者离开了公司，那么没有人了解那些代码了。若是有代码审查的环节，那么至少会有两我的熟悉代码——代码的做者和审阅者。审阅者虽然没有做者对代码那么了解——可是他一样熟悉代码的设计和结构，这些信息是无价之宝。数据结构
固然，没有什么事情是那么简单的。以个人的经验看来，要作好代码审查须要一段时间练习。我注意到经验不足的审阅者一般会落入一些代码审查的陷阱，这些陷阱每每会形成不少的麻烦，给那些但愿尝试代码审查的人们留下了坏印象，成为了他们采纳代码审查的一个主要障碍。架构
代码审查最重要规则是对即将提交的代码中查找问题——你须要作的就是确认代码是正确的。而一般会犯的一个错误，也是刚刚接触代码审查的新手容易犯的一个错误，即审阅者会判断这段代码是否按照本身思路来实现。并发
当有一个问题须要解决时，一般会有几十种的办法。当选定一个解决方法时，会有百万种代码实现。所以，做为一个审阅者，你的工做不是确保代码是按照你的方式来编写的——由于这是不可能的事情。审阅者的工做是确保原做者编写的代码是正确的。若是你没有遵照这个规则，你可能会处处碰壁，审查结束时你的心情很糟糕，对你来讲确定不是一件好事情。
**问题在于这是不自觉就会犯的一个错误。**假定你是一个程序员，当你在看一个问题的时候，你会获得一个本身的解决方案——而且你认为你看到的就是这个问题（应该采用的）解决办法。若是想要成为一名好的审查者，你须要知道这是不对的。
**第二个误区就是人们感受必定要说点什么（才算是作了代码审查）。**代码的做者花了不少的时间和精力来编写代码——你难道不该该说点什么吗？
答案是：你不该该。
若是只是说“哦，这看起来这不错！”，这永远没错。反之，若是你不断地去查找一些“问题”并加以指责，那么我确定你的信誉会荡然无存。若是你不断地去制造一些事情来讲些什么，那么代码的做者会认为，当你的言论只是为了不冷场。今后，你的意见不会受到重视。
**第三个误区就是速度。**你不该该匆忙完成一次代码审查——可是也不要拖延。你的同事在那里等着你的审查结果。若是你和同事不肯意抽出时间来作代码审查或者一直拖延，你们会对此次的审查感到厌烦，也会认为之后的代码审查也只会带来麻烦。看起来好像代码审查会打断你的工做，其实没必要如此。你没必要要在别人要求你审查的时候立刻丢掉手头上的事情。可是在几个小时以内，当你工做中间休息的时候——喝杯茶，去一下洗手间或者聊聊天，散散步。当你再回来工做的时候，你能够开始并完成这个代码审查。若是你这么作了，没有人会站在你身边一直等着你给出审查结果。
在软件工程领域里代码审查能够结束程序员之间无谓的争执。开发者经常会由于一些愚蠢的小事斗嘴，冒犯对方，甚至是在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在团队中是一种很好的工做方式，当某人在团队中出现问题时能够及早的发现。这不只能够帮助你们，还能够交换彼此的进度和想法。
总之，若是你的项目正在进行代码审查，应该作到快速、有效、不浪费别人的时间。正如文章所说的，这几点很是重要。代码审查用意是在代码提交前找到其中的问题。
代码审查能够帮助提升代码质量，避免因为代码习惯而形成的 bug。下面列出的这些要点因该能够做为大部分代码审查的指导，若是是 Java 应用的话，这些建议应该被视做最佳实践。
Javadoc 应该在每个类和方法中添加。
若是是修复某个 bug，应该添加 bug ID。
走捷径的方法或者复杂的逻辑要有解释。
若是代码会被公开，每一个文件头都要标注版权信息。
复杂的 HTML，JavaScript，CSS 应该包含文档。
若是相似的逻辑被使用了屡次，应该把它写成一个帮助类，而后在多出调用。
鼓励使用 API 而不是重复编写代码解决相同的问题。
要强调代码的单元测试。
任何新加的代码不该该破坏已有的代码。
假如是 Web 应用，JSP 不该该包含 Java 代码。
任何代码都不能执行用户的输入，除非转义过了。这个经常包含 JavaScript 的 eval 函数和 SQL 语句。
禁止那些在短期内提交很是多请求的 IP。
任何类，变量，还有方法都应该有正确的访问域。
尽可能避免使用 iframe。
全部数据库和文件操句柄在不须要的时候都应该被关闭。
SQL 语句的写法会致使性能千差万别。
鼓励建立不可变（immutable）的类。
相似的逻辑代码，尽可能经过 if else 语句来实现更多的重用。
尽可能避免使用重对象（heavy objects）。
若是是 Web 项目，请检查是否使用了合适的图片尺寸，CSS sprites 和浏览器缓存等技术。
全局都须要的信息保存在 application context 中。
没有被使用的变量要删除。
针对不一样的 Exception 要用不一样的 catch 语句，而不是一个 Exception 解决全部问题。
针对变量，方法和类要用相同的命名方法。
常量应该被写在独立的常量类中。
每行代码的尾部不要有多余的空格。
对于括号，循环，if语句等等要用统一的格式。
每个单独的方法不该该超过100行。
一个单独的语句不该该超过编辑器的可视区域，它能够被拆分红几行。
检查 String 对象既不是null也不是空的最好方法是 if(“”.equals(str))
假如类有不少成员变量，而且实例化的时候只须要少数变量传入的话，最好使用静态工厂方法，而不是重载构造函数。
给方法添加适当的访问控制，而不是全部都是 public。
遵照项目中使用的框架的最佳实践建议，例如 Spring，Struts，Hibernate，jQuery。
以上的某些注意点能够经过静态代码检查工具完成，例如 CheckStyle，FindBugs 和 JTest。