大家都应该做的 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 工具提交过程过于复杂冗长,相关的工具有很多,不管是开源的还是商业的(比如:PhabricatorGerrit)。GitHub 的 Pull Request 其实是很好的 Code Review 工具。在 GitHub 上,你发现一个好项目想改进它,你只要点击 Fork ,增加你要的功能,然后通过 Pull Request 贡献你的代码。

pr

“废话少说,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

Code Review ,你做了就知道!

微信扫一扫交流

作者:CoderZh
微信关注:hacker-thinking (一个程序员的思考)
本文出处:https://blog.coderzh.com/2015/12/27/code-review/
文章版权归本人所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。