是否要做 Code Review?与 BAT 资深架构师争论之后的思考

摘要: Code Review 至少可以发现一些简单问题…

Fundebug经授权转载,版权归原作者所有。

Code Review 中文叫代码审查,据我所知在很多互联网企业里面几乎没有很好的实践,包括很多像 BAT 一样的大厂,特别是一些业务开发部门,都没有 Code Review 流程,代码写完之后随手提交,然后丢给测试狠命测.

之前跟一个有十几年开发经验的现 BAT 某家的资深员工提起 Code Review 时,其很笃定的讲不可能很好的执行,比较浪费时间,虎头蛇尾等等,一顿否定,又当我提起在 Google 内部开发中 Code Review 是一个执行的很好且已经习以为常的开发流程时,他竟然倚老卖老的说绝对不相信.

一个技术不错,号称架构师,玩转各种框架,中间件的资深 IT 从业者,居然对 Code Review 有如此的偏见,是哪里出了问题,这也是我写这篇文章的原因。本文不是一篇讲如何做 Code Review 的方法论,尽管有所涉及,但更多的是对 Code Review 执行过程中很多团队会遇到的一些问题的思考。

1. Code Review 的意义有多大?

首先来说下 Code Review 的意义,当开发团队对 Code Review 认可了,意识到它的必要和好处了,我想,弄清楚如何快速有效的 Code Review,对充满高智商、高学习能力的 IT 界工程师来讲,也就不是什么难事了。

1)三人行必有我师

永远不要觉得自己很牛逼,或者代码很牛逼,不需要别人 Review;也永远不要觉得自己水平一般,没有资格给别人 Review;更不要觉得大牛让你 Review 代码就只是缺少你的一个 approve,可以随便扫一眼就 LGTM(looks good to me)了。

谷歌在 Code Review 方面执行的很好,尽管谷歌的工程师的平均研发水平都很高,但你会发现,只要是提交 Review 的代码,照样会有很多 comment(修改意见)。即便自己觉得足够牛逼的代码,只要经过不停的推敲,都是有持续改进的空间的。

2)高手之间的过招在细节

只要对技术有追求的团队,就不能把开发当成外包:只要代码可以运行就提交,黑盒狠命测一把,验出 bug 再修复。高手之间过招看的是细节。不同水平的团队,开发相同的业务或者框架,开发出来的东西虽然都能跑,但在可读性,扩展性,性能,可靠性等各种非功能性方面都可能差别很多。

3)Code Review 是摒弃个人英雄主义的作坊式开发模式的有效手段

在一个成熟的公司里,所有的架构设计、实现,都应该是一个团队的产出。尽管这个过程可能会有某个人来主导,但应该是经过整个团队共同智慧的结晶。

如果一个人默默的写代码提交,不经过团队的 Review,这样的代码蕴含的是一个人的智慧。代码的质量完全依赖于这个人的技术水平。这就会导致代码质量层次不齐。如果经过团队多人 Review,打磨,则代码蕴含的是整个团队的智慧,可以保证代码按照团队中的最高水准输出。

4)Code Review 过程是对代码可读性的考察

我觉得,代码的可读性可能比任何方面(扩展性等)都重要。可读性好,代表了后期维护成本低,线上 bug 容易排查,新人容易熟悉代码,老人离职时代码容易接手,而且可读性好,也说明代码足够简单,出错可能性小,代码的组织架构合理。

而 Code Review 是考察代码的可读性的一种很好的手段。如果代码审查者(Reviewer)很费劲才能看懂你的代码,说明这段代码的可读性就有待提高了。

5)Code Review 可以提高代码质量

这个很多人都认可,前面也讲到了。不过我补充一点我的体会:有句名言:旁观者清,当局者迷。自己写代码的时候,写的晕乎乎的,有时候将代码提交 review board(code review 的工具界面)之后,自己的改动都放到一块,清晰可见,一目了然,有时候还没有等其他同事 review,自己就先发现了很多问题。

6)Code Review 过程是一种 mentor(传帮带)的有效途径

团队讲求传帮带,如何来做呢?当然,业务上面,我们可能通过文档,口口相传,那技术呢?如何培养初级工程师的技术能力呢?Code Review 就是一种很好的途径,每次 Code Review 的过程都是一次真实的案例讲解,是从大牛身上学习技术的很好途径。

7)Code Review 保证不止一人对代码熟悉

如果一段代码只有一个人熟悉,如果这个同事休假了离职了,交接起来就比较费劲,有时候单纯看代码还看不大懂,又要跟 PM、业务团队、或者其他技术团队,再重复来一轮沟通,搞的其他团队的人都很烦你。而 Code Review 保证任何代码都至少同时有两个同事熟悉,除非两个同事同时离职:(

8)Code Review 可以打造良好的技术氛围

提交代码 Review 的人,希望自己写的代码足够牛逼,毕竟被同事 Review 出很多烂代码,是件很丢人的事情。而做 Code review 的人,也希望自己尽可能的提出有建设性第一件,展示自己的能力。这本身就能增进技术交流,活跃技术氛围,培养大家的 Geek 精神,对代码优美的追求。

9)Code Review 是一种沟通方式

Talk is cheap,show me the code。怎么”show”,通过 Code Review 工具来”show”,这样也方便别人反馈意见。特别是跨不同办公室、跨时区的沟通,Code Review 是一种很好的沟通方式。我今天白天写的代码,明天来上班的时候,跨时区的同事已经帮我 Review 好了,岂不是感觉很好。

10)Review 提高大家自律性

开发过程难免有人不自律,或者偶尔有侥幸心理,反正也没人看,随便写写就提交了。Code Review 过程相当于一次代码直播,曝光 dirty Code,有一定的威慑力,大家就不敢随便应付一下就提交代码了。

2. Code Review 反对声音有哪些?

上面讲了这么多 Code Review 的意义,虽然大部分人都认可,但还是有很多反对的声音,我们来看看都有哪些反对的声音?

1)有人认为 Code Review 流程太长,太浪费时间,特别是业务逼,工期紧的时候,今天改的代码,明天就要上,如果等同事 Review,同事还有可能没时间。

我所经历的项目,还没有一个因为工期紧导致没有时间 Code Review 的。而且 Code Review 熟练之后,并不需要花费太长的时间。尽管开始做 Code Review 的时候,你可能因为不熟练,需要有一个 check list 对照着来 Review,比较耗时,但当你熟练之后,Code Review 就像键盘盲打一样,你已经忘记了哪个手指按的是哪个键了,扫一遍代码就能揪出绝大部分问题。

2)有人认为有了黑盒测试,写的代码给测试团队测试就 ok 了,Code Review 没有必要,ROI(投入产出比)不高。

黑盒测试只能测试代码的正确性,对于很多非功能性的,比如代码的可读性,扩展性,组织结构是否合理,性能问题等都是无法考察的。

3)有人认为业务一直在变,今天写的明天可能就改,代码有可能不会维护很久,代码写得太好也没用。

这种现象在游戏开发、一些早期的创业公司、或者项目验证阶段比较常见,讲求短平快,先验证产品,再优化技术,如果确实面对的还只是生存问题,代码质量确实不是首要的,特殊情况下,不做 Code Review 是支持的!

3. Code Review 如何落地执行?

知易行难,有些 leader 已经认识到 Code Review 的必要性,但执行起来又困难重重,下面罗列了我所经历的一些困难,以及相应的应对策略。

1)团队成员水平比较低,不知道 Review 什么,也 Review 不出什么。自己代码都没写明白,不知道什么是好的代码,什么是差的,更不要说告诉别人了,大眼瞪小眼,只能 Review 点语法的了。

这种情况也挺常见,不过没关系,团队的技术水平都是可以培养的。我们可以先让资深同事。技术好的同事、或者 leader,来 review 其他所有的人的代码。Review 的过程也是一种 mentor 的过程,慢慢的大家都知道哪样的代码有问题,应该从哪些方面 Review。虽然这可能会有一个相当长的过程,但如果真想在团队中实行 Code Review,这不失是一种曲线救国的方法。

2)还有一种情况是,开始的时候大家 Code Review 都还挺认真,但是时间长了,大家觉得这事跟 KPI 无关,而且我还要看别人的代码,理解业务,多浪费我时间啊。慢慢地就会发生这样的情况:有人提交了代码,随便抓个人 Review,Review 的人也不认真,随便扫一眼就点 approve 了。一旦发生破窗效应,Code Review 也就会变成流于形式了。

我的对策是:一方面,要明确的告诉 Code Review 的重要性,要严格执行,让大家不要懈怠;另一方面,是否可以间接的跟 KPI,升职等联系在一块,senior 的工程师有义务做 Code Review,就像技术面试一样。再次,想办法活跃团队的技术氛围,把 Code Review 作为一种展示自己技术的机会,带动起大家 Code Review 的积极性,提高大家都 Code Review 的认同感(也算是洗脑吧)。

多说几句:Google 的 Code Review 是做的很好的,可以说是谷歌保持代码高质量最有效的手段之一。Google 的 Code Review 非常严格,多一个空行,多一个空格,注释有拼错的单词,变量命名的不够好,都被指出来要求修改。而且,所有的项目都要求 Code Review。

关于Fundebug

Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了20亿+错误事件,付费客户有阳光保险、核桃编程、荔枝FM、掌门1对1、微脉、青团社等众多品牌企业。欢迎大家免费试用

版权声明

转载时请注明作者 Fundebug以及本文地址:
https://blog.fundebug.com/2019/03/28/is-code-review-necessary/

您的用户遇到BUG了吗?

体验Demo 免费使用