阅读 4342

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

关注我的微信公众号:小争哥,获取更多、更新的技术、非技术分享。
作者:前Google工程师,5万人订阅《数据结构和算法之美》专栏作者。
希望通过我加速你的技术、职场进步。

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。

欢迎留言区说说你对Code review的看法,你们公司是否有Code Review,在Code Review的过程中遇到了哪些问题?

关注下面的标签,发现更多相似文章
评论