关于文章的说明，写在前面
最近懒，脑子开始冬眠了，就先翻译别人的文章凑下字数吧。这次选的是关于code review最佳实践的文章，
原文点击就可以看到。这是百度搜索到的一篇文章，我也不确定质量咋地，没连没办法，先找点事情做。
下面开始正文部分。
一个成功的同级复查的code review策略，需要在严格的文档化流程和没有威胁的相互协作的环境中找到平衡点。
高度标准化的同级代码复查会扼杀生产力，而懒散的流程通常又没有效率。
管理者有责任找到一个中间立场，让同级代码复查既高效且有效，还能在成员间培养开放的沟通和进行知识共享的环境。以下10条秘诀带你飞，高效code review不是梦
1.一次回顾代码行少于400
一项聪明熊对思科系统程序开发组的研究表明，开发人员一次应该复查不超过200到400行的代码，因为人的大脑一次最多能够有效的处理这么多的信息，超过400行发现代码缺陷的能力就会变弱。
在实践中，花60-90分钟复查200-400行代码能够找到70-90%的错误。所以如果代码里存在10个缺陷，一个合适的引导的复查可以找到其中的7到9个。
2.别着急，审查代码要低于每小时500代码行哦
假设在复查的时候别人都找到错误而你啥都没发现，可能会有点小忧桑。但是聪明熊的一项调查显示，
缺陷密度在速度快过每小时500代码行的时候显著下降。代码复查在合理的质量以及给定的时间用更慢的速度最终会是最高效的代码复查。
3.一次回顾不要超过60分钟
正如你不应该复查代码太快，你也不该一坐下来就复查代码太长时间。当人投入到某件需要一段时间段集中注意力的活动中时，60分钟后表现就开始下滑了。研究表明在过程中歇一会能够明显提高工作质量。
4.设置目标，并且可以得到指标
在执行一个流程之前，你的团队需要决定如何度量同级复查的有效性并对可量化的目标命名。
使用SMART标准（Specific、Measurable、Attainable、Relevant、Time－based）,先从外部着手。比如"减少15%的"或者“减少由开发引入的一半比例的缺陷”。这些信息能够给你一个确定可量化的代码提高的图景。“修复更多的bug”不是一个有效的目标。
查看一些内部指标也能起到帮助，包括：
- 代码审查率：执行代码审核的速度；
- 缺陷率：每小时复查发现bugs的数量；
- 缺陷密度：每行代码发现bug的平均数值；
实际上，只有自动化的或者严格控制的流程能够提供这些重复性的指标。
一个指标驱动的代码复查工具能够自动地收集数据，这样你的这些信息是精确的没有包含人类偏见的。
5.在复查之前，作者先注释代码
写代码的人应该在代码复查发生之前注释代码，是因为注释会引导复审者回顾所有的更改,展示哪些文件要先看以及每行代码修改原因。
注释应该帮助其他复查者简化流程并提供更多的上下文。另一个额外好处是,写代码的人往往在同级代码复查甚至之前就会发现额外的错误。同行评审之前发现更多bug将会有更低的缺陷密度,因为整体会有更少的缺陷存在。
6.使用清单
很有可能你们团队的每个人总是重复犯通好样的10个错误，遗漏是尤其难发现的缺陷,因为很难复查不存在的东西。清单是最有效消除经常错误的方法，同时应对查找遗漏这个挑战。
7.对于找到的缺陷建立流程去修复哦
即使对代码复查流程完成 设置时间盒限制、限制每小时代码复查行数、命名关键指标这些优化之后，你仍然遗漏了一个关键的复查步骤。这些bug最终怎么被修复呢？答案很显然，但是很多团队并没有一个系统性的方法来修复这些他们花费如此多辛苦发现的bugs。
确保所有bugs被修复的最好的方式是使用一个团队协作的代码复查工具来让复查者记录bugs，和写代码的人讨论，确认代码的修改。
如果没有自动化的工具，在代码审查里面发信啊的bugs不会记录到团队通常使用的缺陷跟踪系统中，因为这写bugs是在发布给质量分析师之前发现的。
8.建立一个积极的代码复查的氛围
同级复查会让团队的人际关系变得紧张。你代码中的每一个片段被批判，被管理评估然后测量代码中的缺陷密度，这很难去接受。因此，为了让同级代码复查能够成功，管理者床罩一个互相协作彼此学习的同级复查文化相当的重要。
即使很容易感觉缺陷很纯粹的消极，但事实上每一个bug对于团队都是一个提高代码质量的机会。同级复查能够让初级的成员去向高一级的主力成员学习，也能帮助一些老程序员改掉坏习惯。
在同级复查中发现的缺陷不是一个能够接受的用来评估团队成员的指标。从统计代码复查中得到的报告不应该用在个人表现报告里面。如果个人指标成为提升和获得补偿的一个基础，开发人员将会仇视流程并自然而然关注提高个人指标而不是写对整体更好的代码。
9.拥抱自我效应的影响
知道别人会看他们的工作必定会驱动人创造更好的产品。这种“自我效应”自然鼓励开发人员编写干净代码,
因为一起工作的人一定会看到它。聪明熊思科系统的研究发现,花最少的时间开销“现场抽查”20%到33%的代码会有较低的缺陷密度。如果你的代码有三分之一的机会被审查,你会有足够的动力去仔细检查自己的工作。
10.实践轻量级的代码复查
在电子邮件、一起在桌子边面对面、Word文档、其他辅助工具和各种混合方式中，确实有无数种方法可以协作开展评code review。然而，为了更省团队的时间且有效，建议使用轻量级的、基于工具辅助的流程。
聪明熊对思科系统研究发现，轻量级代码评审花费的时间不到正式评审的20%，但发现的bug也一样多!正式的或重量级的检查平均每200 LOC 9小时。即使严格的流程是很有效的，但它需要6个参与者和几个小时的会议来翻看详细的代码打印输出。