当前位置:网站首页>cr1

cr1

2020-12-06 10:38:36 木九天

Code Review 是软件开发过程中非常重要的一个环节,不过相对于单元测试,大家可能接触更少,同时,想要做好 Code Review 往往也更困难。

什么是 Code Review?

Code Review 翻译成中文是代码评审,具体的定义可以看 wiki。这篇 wiki 介绍说 Code Review 在帮助团队找到代码缺陷这件事上作用巨大:“代码审查一般可以找到及移除约65%的错误,最高可以到85%”。实际上, Code Review 的好处远不止这一条,它至少能在以下三个方面帮到我们:

  1. 传播知识

相信很多人第一次提交 Code Review 都有类似的经历:短短几百行代码,却被提了密密麻麻几十条 comments,更新了十多次代码,才最终被 accept 。其实当代码被 accept,提交代码的工程师通过这次 review 就学习到了代码规范和很多好的实践。同时,通过 review 更资深工程师的代码,年轻的工程师也更直观地学习架构和编码;另外,工程师之间也可以通过 review 代码来共享项目知识,看代码实现在绝大多数时候是了解项目的最好方式。

2、增进代码质量

这点也很容易理解,有经验的工程师可以在架构设计、代码细节等各个方面帮助到初学者。不同工程师也会有知识盲点,互相 review 进步也很快。另外,被 review 的代码质量更高还有一个很多人注意不到的心理因素:在状态不佳的时候,工程师难免会匆忙写些“潦草”的代码,但是当你知道自己的代码会被review 的工程师提交 comment 打回来,自然会更仔细些 : -)

3、找出潜在的 bug

这是大部分团队进行 Code Review 的目的。就像上面提到的,Code Review 在这方面效果不错。其实我认为大部分代码 bug 应该由单元测试,功能测试,性能测试和回归测试来保障。不过由于静态分析不理解业务,另外有些 bug 在测试中并不容易复现,这两种情况下,经验丰富的工程师来 review 代码就尤其重要了。

接下来想谈的是做 Code Review 的根本原因是什么。

毕竟 Code Review 是在编码过程中加了一道流程,又需要很多交流沟通,review 双方甚至可能由于编程理念不一样而产生争执,各种原因导致做好 Code Review 并不容易。现实情况确实如此,比如 v2ex 上有个帖子:发起个讨论,你们公司有 code review 吗? ,一百多位工程师回答了这个问题,从他们的答案中可以看出,做好 Code Review 的公司寥寥无几。即使在一线互联网公司,也有不少团队反对 Code Review ,陈皓就写过一篇文章:《从Code Review 谈如何做技术》 ,提到了在阿里实施 Code Review 遇到的阻力,反对的原因是工期紧、需求变更快。如果不想清楚为什么要做 Code Review ,遇到障碍会非常容易妥协,慢慢 Code Review 就会走样,最终流于形式。反之,在我们遇到障碍,review 代码不顺利时就会以积极的心态来解决问题。

在我看来,我们在完成编码工作的同时,也需要时时分享架构设计,交流各自的代码,Code Review 正是时时分享架构设计,交流代码最好的方式。这是我们需要做 Code Review 的根本原因。交流代码的频率非常重要,在你构思好设计,有了骨架代码,写完一个功能后都应该及时提交 review,以便其他工程师能够及时了解你的思路,和你沟通实现细节。而那些认为代码只要能运行就好,或者认为没人应该对自己代码指手画脚的人显然和你我不同,他们不会是这篇文章的读者 : 

那么我们怎样做好 Code Review 呢?两个方面:一是减负,Code Review 只做它应该做的事情。二是提高 Code Review 的效率。

Code Review 应该讨论的是功能实现、架构设计、代码质量,不应该做以下两件事情。

1、检查代码风格和编程规范

除了新人,其他工程师提交的代码不应该通过 review 来确保代码风格。这里所说的代码风格包括但不限于:命名规范、代码缩进、注释和文档等等。你可以利用 IDE 或者其他工具来保证编程规范和代码风格的统一。如果你在制定团队的代码规范,可以 follow Google Java Style 或者 Facebook Coding Standards 。在这里我推荐好好看看 Facebook 的规范,因为 Google 的代码规范告诉你应该怎么做,而 Facebook 的规范解释了为什么要这样做,以及在什么情况下需要权衡。

2、检查常规的 bad smell 和代码 bug 。

《重构》 和 《Clean Code》 对代码 bad smell 都有非常详细的描述。团队的工程师应该熟读这两本书,避免这些 bad smell,比如:重复代码、过长函数、过大类、过于亲密的两个 classes 等,你可以利用 IDE 和静态代码检查工具 checkstyle、 findbugs 和 pmd 来帮你检查出这些问题。同样,代码中的大多数 bug 也不应该在 Code Review 阶段来发现,你应该通过静态工具、单元测试、集成测试和性能测试来发现它们。

再说说如何提高 Code Review 的效率。

版权声明
本文为[木九天]所创,转载请带上原文链接,感谢
https://my.oschina.net/mdxlcj/blog/4776704