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

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

在 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 微博账号发布更多关于团队协作、团队管理方面的思考。谢谢！