大家都应该做的 Code Review

代码审查（Code Review）是个老生常谈的话题了，我以前呆过的大公司也好，创业公司也好，都知道 Code Review 的好处，但真正去有效执行的却很少。有人认为“存在即合理”，大家都不愿意做 Code Review ，可能 Code Review 真的不好，影响开发效率。有的人想做，但是执行起来太困难。

造成大家放弃 Code Review 的原因有哪些呢？我仔细想了想，大概有这几种：

1. 时间紧：项目赶着上线，一个人干两人的活，天天加班累成狗，哪有时间 Review ，怕影响项目进度。
2. 等不了：工作被阻塞，发起评审后，啥也干不了了，我是该催一催那家伙评审一下呢，还是催一催那家伙评审一下呢，什么？他休假了！WTF！
3. 效果差：我写的那么有气质的代码你看出来了吗？看出来了吗？！什么？！单词拼写错误？代码逻辑为什么是这样？来来来，搬个小板凳过来，我给你解释一下午。（评审者不了解被评审人工作）
4. 嫌麻烦：代码不能直接 commit 或 push ，必须先走评审流程，还能不能愉快的提交代码了？

再加上，创业团队成功率本来就低，一种普遍的想法是：最重要是项目能活下去，代码写的挫一点没关系，可以以后再搞。代码写的再好，项目死了也是白搭。

貌似好有道理啊，要不 Code Review 就不做了吧。不！我认为，不论大小什么团队，都应该做 Code Review 。

我的核心观点是，产品开发周期内，代码编写所占的时间比例其实是很小的，之后有大量的时间是花在代码调试，修复 Bug 和填之前的坑上。**做 Code Review ，其实可以减少代码调试的时间，更快的定位和修复 Bug 和少挖一些坑。**在代码编写的阶段通过 Code Review 把控质量，从总的项目周期来看是划算的，甚至是事半功倍的。

当然，上面提到的“时间紧、等不了、效果差、嫌麻烦”也是真实存在的。要做好 Code Review ，就必须去解决这些问题。核心是提高 Code Review 效率，我的建议也很简单，用好的工具，做充分的沟通。

首先要避免 Code Review 工具提交过程过于复杂冗长，相关的工具有很多，不管是开源的还是商业的（比如：Phabricator、Gerrit）。GitHub 的 Pull Request 其实是很好的 Code Review 工具。在 GitHub 上，你发现一个好项目想改进它，你只要点击 Fork ，增加你要的功能，然后通过 Pull Request 贡献你的代码。

“废话少说，Send me a pull request!” 是不是感觉这句话叼叼的。

GitHub 的 Pull Request Merge 相当于 Code Review 的过程，代码原作者 Review 代码，提出意见，最终合并只需要在 GitHub 点几个按钮就可以完成。据了解，已经有不少创业公司的代码直接托管在 GitHub，并采用 PR 的开发模式。

其次是要做好充分的沟通。实现某个功能时，可以指派给两人，一人负责写代码，一人负责跟踪和讨论，然后交叉进行，有点类似结对编程。如果做到这个比较难，那就需要在代码编写过程中尽可能多的和别人讨论沟通，让评审者充分了解你的工作。可行的方法是老员工带新员工，老员工对新员工的工作比较了解，可以很好的给出评审意见。另一种是老员工之间互相评审，互相交流容易擦出火花。

而且，做好 Code Review ，除了提高代码质量之外，还可以：

1. 把控代码的风格和规范，提高代码的可维护性。
2. 展示自己的工作内容，让同事对你的工作成果更加了解。
3. 从别人的代码里学习到很多编程技巧，解决问题的思路。
4. 通过别人的评审意见发现自己的不足，优化自己的代码，扩宽自己的思路。
5. 很好的给予新人指导，给出有建设性的意见，帮助新人成长，做好知识的传承。
6. 通过评审摩擦火花，互相欣赏，找到心灵相惜的好基友或终身伴侣。

Code Review ，你做了就知道！