1、Why Code Review
Code Review是什么
Code Review最直观的解释即看代码。常规的做法为自己看，有时代码逻辑问题可能自己看不出来，需要找同事一起看，在大家知识体系相对平均的情况下可能需要花钱专门的公司帮助查看。
Code Review需要看哪些？对于刚入职场或者刚接触到Coding的新人来说，代码风格是比较重要的一块。除此之外，编码规范及代码结构写法，框架和工具的选型，具体项目的业务逻辑，安全隐患，性能问题等都可以通过review的方式发现。Code Review从前往后大致分为结对编程，提交代码后，测试之前，发版之前，发版之后等几个阶段，越往后，Code Review的效果越差，修复的成本也越来越高。
为什么一定要做入库前Code Review
首先，代码审查的最大的功用是纯社会性的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释和程序结构。
其次，偷懒是人的天性，从节约成本的角度考虑，大家一般会选择在测试之前无限制的Delay Code Review。入库前做Code Review便是成本和效果之间最佳平衡点，它能及时发现问题，进行修改后确保代码质量。
最后，代码审查能传播知识。在很多开发团队里，经常每个人负责一个核心模块，每个人都只关注自己的模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解，但至少他会熟悉程序的设计和架构，这是极其重要的。
2、Gerrit简介
Gerrit是Google为Android系统研发量身定制的一套免费开源的代码审核系统，它在传统的源码管理协作流程中强制性引入代码审核机制，通过人工代码审核和自动化代码验证过程，将不符合要求的代码屏蔽在代码库之外，确保核心代码多人校验、多人互备和自动化构建核验。
Gerrit之前的系统架构
Gerrit之后的系统架构
通过Gerrit机制将代码做分隔。
Gerrit适用性
几乎任何需要正式发布的项目都应当使用Gerrit来进行代码审查，如果Team中有新人，必须使用Gerrit确保代码质量。
Gerrit效果
整体上来说，个推使用的标准配置为Gerrit+Jenkins+Sonar，整个系统搭建完成后得到的效果为：100% Code Style问题避免入库，80% 设计问题避免入库，40% 逻辑错误避免入库，20% 安全隐患避免入库，100% 人员互备。
3、Gerrit入门实战
Gerrit部署和运行
JDK环境配置
java -jar gerrit-2.12.war init -d review_site
Gerrit人员角色配置
使用OpenID登录，第一个登录的用户为admin，创建dev帐号、review帐号和verify帐号，创建dev、review和verify用户组并添加相应用户，注意设置Username，代码同步时需要用到。
创建第一个项目，配置权限管理
添加project，选择 Inherit From All-Projects，当然也可以自定义Parent Project。
添加Verified标签支持，这里修改All-Project 项目的project.config，所有继承自All-Project的项目自动添加Verified 标签，也可针对项目自定义是否verify。
创建用户组
添加相关用户权限
将代码库同步到本地（SSH/Http）
HTTP 方式:
HTTP Password 密码在 账户 - ->> Settings -->> HTTP Password 处获取。
SSH方式:
添加SSH Public Key。
Clone代码到本地
commit-msg ,提供自动写入change-Id 至git log内功能
提交第一个change
Gerrit上进行代码审查，确认入库
Verify:
工程里面接入了jenkins自动verify，结果可在上图红框内展示verify结果。
review代码，提交入库。
本地代码库更新，获取最新入库代码
代码submit后通过git pull - - rebase 更新代码。
Gerrit入门实战-初级修补
如果所有代码提交均被打回，可以进行暴力回滚：git reset <commit>，接着重新提交Gerrit，再进行Gerrit审查入库。
Gerrit入门实战-高级修补
如果单个提交打回，则可交互式回滚：git rebase -i <commit>，修改指定commit点：git commit --amend，完成所有commit点处理：git rebase --continue，然后重新提交Gerrit，最后Gerrit审查入库。
Rebase前
Rebase 后
rebase 在同一个点上修改，不会产生审核点，多个commit点同时存在是尤其有用。
Gerrit经验谈
第一，Git别名绑定，添加别名字段，通过git review master这样简单语法提交到master源端分支，可以省去很多工作。修改系统目录或者项目目下的.gitconfig 文件，添加
也可通过git config --global alias.review 命令修改
第二，工具只是一部分，更重要的是人与人当面的沟通交流，大家讨论一个好的解决方案，才能更好的解决问题。没有交流，工具也就失去了意义。
最后，关于review积压问题，要避免提交积压，代码审核过程要及时完成，避免 Code Review流于形式。
从个推实际使用效果看，Gerrit在核心代码质量控制、知识传承、团队培养等方面都具备很高的实用价值，推荐给广大开发团队用。
原文地址：http://blog.51cto.com/13031991/2107999
