code review的做用

知乎上有个问答：你们的公司的 Code Review 都是怎么作的？遇到过哪些问题？不少答主都提到Code Review的做用是提早发现bug、提升代码质量，顺带统一团队编码规范等等。

秀一下咱们的几回CodeReview。

提早发现bug

当了爸妈了以后，人都不免有“不让孩子再吃本身吃过的苦”这样的想法。其实reviewer也会有这种“老父亲/老母亲”的心理：“不让别人再踩本身踩过的坑”。

好比这段讨论。为了把一个对象中的字段转为Map（key为字段名、value为字段值），咱们有这样一段代码：

围绕这段代码，咱们有这样一段review（聊天）:

首先，有同事L在review时提出能够用反射来作，并表示在另外的某个地方有现成的代码可供参考。随后，另外一位同事S微微一笑：“在你来以前咱们就用过反射了”，并指出了使用反射可能带来的问题。同事L恍然大悟，在同事S的明教之下，修改了他的代码，避免了一个因为对技术理解不够透彻而致使的bug。

那是否是只有技术大牛可以在review中提早发现bug呢？显然不是。除了技术不足的缘由，对业务理解不够也会致使bug。而这种bug一样能够在“老父亲/老母亲”的目光下被提早发现并解决。

例如，某次需求在系统增长了这样两个枚举：

关于这两行代码，有这样一段review：

这段review与技术无关，它指出的是一个纯粹的业务bug：这个枚举所处理的业务要求它的构造方法中的第一个参数必须是“xxx.SUCCESS”或者"xxx.FAIL"格式。虽然写代码的同事并不熟悉这个业务要求，可是好在熟悉业务的同事参与了review，并提早发现了这个bug。

那么，是否是只有精通技术、或者熟悉业务，才能参与code review，并发现潜在的bug呢？其实也不是。咱们再看看这段代码：

• 
  

这里的review简单明了地指出其中的问题：

这个bug的缘由与业务无关，也不涉及多么高精尖的技术，纯粹就是开发人员粗枝大叶形成的。只要认真参与review，就能发现这种粗枝大叶、一时手误的问题。

提升代码质量

提升代码质量、提高开发技术，应该说是每一个程序员的目标。实现目标的方式有不少，参与code review就是其中一种。不管是看别人写的代码、仍是看围绕代码展开的讨论，都有“他山之石能够攻玉”的做用。

例如，咱们有这样一个类：

关于它，咱们有这样一段review（聊天）：

看完这段review，是否是对SpringMVC和HttpServletRequest有多了一点了解？若是有兴趣再去钻研一下“SpringMVC其实还有其它方法来实现这个功能”，是否是又能百尺竿头更进一步了呢？

又如，围绕Controller是直接操做Response、仍是封装ResponseEntity来返回InputStream，咱们也有这样的review（聊天）。相信不管对三位直接参与者仍是众多围观者，这段讨论都会大有裨益：

统一团队规范

其实我的以为……统一团队规范这个做用在review中算是名列“后”茅的了。可是在实践中，不少review都是从检查编码规范开始的：命名啦，注释啦，换行啦，空格啦，等等。有时甚至会给人一种“review就只能检查检查代码规范”的感受。

这种感受固然是错觉，咱们在review中引起的讨论、发现的bug就是明证。可是，就如张国荣也要苦熬十年同样，咱们也在“review就只能检查代码规范”的泥潭中跋涉了好久。这实际上是开展code review的必经之路。一方面，从未经历过review的团队，其代码规范确定存在问题——要么有规范不遵照，要么压根没有规范。另外一方面，对于reviewer来讲，规范问题是最容易被发现一类问题。这两方面凑到一块儿，规范问题还不一抓一大把么？

要从这个泥潭中走出来，最根本的法子就是团队真正的创建规范、遵循规范、重视规范。只有作到了这一点，code review才能有效地提早发现bug、提升代码质量。