让代码审查成为你的团队习惯

在 「远程工做经验谈 - 如何适应及如何管理」 一文中，我在规则这章节提到了代码审查，收到很多朋友的提问和反馈，故在本文中拓展开来聊聊。

在 Wikipedia 上，对代码审查的定义是

代码审查（英语：Code Review）是指对计算机源代码系统化地审查，经常使用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提高软件质量及开发者的技术。代码审查常以不一样的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查[1]。

能够看出，代码审查主要是为了软件质量和我的开发修养。巧合的是，但凡我接触过的靠谱的团队，无一不是在团队中推行严格的代码审查制度。这个就像是一种习惯，直接融入在团队血液之中。

为何咱们要求代码审查

人们习惯用本身能衡量的东西来判断一件事情，因此对于代码审查而言，咱们能看到的是它须要花掉一些人的一些额外的时间，那些本应该用来继续作开发的时间。这也正是代码审查在团队推行遇到的最大阻力。

在咱们 Pragmatic.ly 的实践中，代码审查给咱们带来的三点好处。

1. 代码审查保证软件质量。咱们团队没有专门的 QA 人员，测试通常由完成功能的程序员完成，思考不够周全，有时也达不到彻底的测试覆盖率，咱们在作代码审查时已经不少次发现过当事者没考虑过到的设计细节和一些实现上的 bug。它已成为咱们团队找 bug 的一大手段，对于软件质量保证有很大贡献。在有些严格的团队如 Facebook，每个修改若是没有被 3 个不一样的成员审查经过，代码都不能作发布。
2. 代码审查促进团队成长。经过代码审查，每一个人能够学习到其余人好的的思惟方式和编码方式，也会提出作的很差的地方和改进意见，是整个团队在代码级别的另外一种沟通和思考。我发现过了一段时间后，团队的成长是喜人的。对于专门花时间去作培训，成本低多了，XD
3. 代码审查避免单点故障。每一行代码，团队里至少有两我的以上是了解的。因此万一出了问题，即便代码编写者不在，咱们仍然有其余人能马上去修正。经理不再担忧出现虫子了。并且，视团队状况，最好尝试交叉审查，不要总是 A 审查 B，B 审查 A，换着审查效果更好。

若是你的团队尚未作代码审查，我很建议去尝试几个迭代周期，而后作个过程回顾，看看是否适合于团队，我相信结果确定不会让大家失望，:)

代码审查应该是群体行为

这个是我在不少团队看到的问题。有些团队虽然在作代码审查，可是主要仍是为了保证软件质量，没有最好的发挥代码审查的威力。我听过过不少次“他们经验比较浅，可能没法对别人的代码作审查”。不，不是这样子的。代码审查应该是群体行为，与经验无关。俗话说，三个臭皮匠，顶个诸葛亮。即便是经验欠缺的团队，若是能群策群力，也能交付出顶级质量的软件。这里先不论代码审查对团队的成长，单单是每一次修改都让其余人审查的行为，就能提升初级程序员的信心、对产品的参与度和责任心。反之，有些人会一直呆在舒服区，反正有人帮忙作审查提意见。

Do it and get surprised!

咱们团队如何作代码审查

我在 Intridea 和 Pragmatic.ly 作项目管理时都作代码审查，主要尝试过两种方式，最经常使用的是 Github 倡导的 Pull Request，还有就是结对编程。

Pull Request

这是咱们最经常使用的方式，咱们用 Pragmatic.ly 作项目管理，用 BitBucket 作代码版本控制系统。每一个任务都会基于线上版本开一个新的分支，当任务完成后，提交推送到 BitBucket 的时候，会自动的关联这个提交到 Pragmatic.ly 中，也建立了一个 Pull Request。当有 Pull Request 出现时，咱们的原则是谁有空谁审查，并不指派到人。整个审查过程，提意见，作修改，直到被经过，等待上线。具体例子能够见下图，

值得一提的是，咱们在作代码审查的时候会关注下面一些问题。

1. 基本功能工做不，要实际跑起来看。
2. 代码实现清晰易读吗
3. 有没有没有考虑到的点，特别是对其余部分代码会否形成影响
4. 是否是最好的实现，有没有重构的空间
5. 测试代码一样须要审查

若是你对 Pull Request 方式感兴趣，推荐一个我很是喜欢的 Talk，来自 Zach Holman 的 「How Github Uses Github To Build Github」。Zach Holman 也是咱们今年 RubyConf China 的邀请嘉宾，欢迎广大 Ruby 爱好者来京交流，XD

结对编程

由于咱们是一直在远程工做，因此对于结对编程实践并很少。在有限的几回里，咱们是用一个共享的 VPS + TMux 结对，也有时用 GoToMeeting 这样的在线会议系统作结对编程。结对编程等同于实时代码审查，有限的几回结对编程体验都不错，开发效率提高飕飕的，也是很好的互相学习的机会，可是太累了，同时由于远程的缘故受网络条件制约太多.... Kevin 曾在 Teahour 里分享过他们在 HashRocket 的结对编程经验分享，叹为观止，有兴趣的能够听听这一期。若是大家团队在一块儿办公，推荐尝试一下结对编程，不过严格的每一个任务都作结对编程不推荐。

建议

以上就是咱们团队在代码审查上的经验和思考，但愿对你有帮助。让代码审查融入团队的血液，成为大家的工做习惯，绝对会是大家在团队管理上作出的最正确的决定之一，去尝试吧！若是对于代码审查实践或者团队管理上面有任何想交流的，欢迎随时联系我，任何我列出的联系方式均可以。

最后，上篇博客最后一段颇有用，收获了很多关注者，因此故伎重演，XD。若是你读到这里了，那么你应该在微博上加我为好友。我也会在 Pragmatic.ly 微博帐号发布更多关于团队协做、团队管理方面的思考。谢谢！