微信号:daiziguizhongren

介绍:深度分析大数据、深度学习、人工智能等技术,切中实际应用场景,为大家授业解惑.间或,也会介绍国内外相关领域有趣的面试题.

陈老师|我的“code review”成长之路

2016-09-09 00:08 陈老师

“code review”已经是很多公司的常规实践,初看上去好像是浪费时间,降低工作效率,其实反之,好处大家有目共睹。它能检查代码的正确性,合理性,安全性,发现隐秘的bugs,让系统更可靠的运行。它能保证代码能有两个或以上的人熟悉,促进知识共享。它能让团队成员互为备份,互相支持,不会有SPOF。它能威慑埋雷的任何想法,杜绝邪念。它能互相学习好的代码,提高编程技能。等等。


从毕业开始工作到现在,我对“code review”的认识也越来越深刻,越来越感受到它的重要性,对产品研发的不可缺失。在我的成长过程中,经历了“code review”的不同角色,每个过程,每个角色,都经历了很多,积累了经验。


作为初出茅庐的创业者


从学校毕业不久,出来和朋友一起创业,那时就知道埋头苦干,不讲方法,快速出来产品系统是首要唯一任务。所有的事情都得自己做,加班加点,人也不多,各做各的,相互之间根本没有什么code review,谁写好了,谁就commit到代码库,经过简单测试,就可以上线了。不行回滚,修复了再上,完全就是初出茅庐的原始人的做法。那时,经验不足,考虑不周全,系统经常会出问题。调试bug的过程中,耗时耗力,当时就会有同事一起调试,一起看代码,最原始的非正式的code review就是那时开始的。当初的经验教训就是,debug sucks,test rocks,code review even rockets。


作为代码提交者


刚出道时,作为新人,更多的是写代码和让高手审查,也慢慢学习怎么审查。


首先,必须了解和学习公司的code review 规范流程。最先学习了不同编程语言的code style,并且要求通过公司的code style测试,也叫做code readability(代码可读性)测试。之后一定按照style规定来写代码,包括怎么定义变量名,函数名,类名,如何使用空格,怎么写注释说明,哪些语法不鼓励甚至禁止使用,等等,这样做的好处是提高代码的可读性,一致性,可维护性。有了好的训练,一辈子受益的事情。公司开发了code style检查工具,使用工具来检查代码的可读性,不符合的立即修正。


写代码之前,设计好项目的目录结构,模块结构,对象结构,保证代码的整体结构合理。这样,别人一看目录就能知道项目要完成的任务,每个文件要做的事情。


进入编码阶段,先勾画出大体框架,然后一个一个细化,代码漂亮,结构合理,算法精致,执行效率高。能复用的尽可能复用,因为那些代码经过了很多测试,质量有保证。


每写完一个部分,一定要完善测试用例,主要是白盒单元测试。整体写完之后,要有集成测试,回归测试,甚至负载测试,等等。编译,测试,整合到脚本里面,这样,每次修改,就能运行脚本自动完成各种测试,保证质量。


一个大项目的各个可以独立完成的任务,实现和测试好了之后,打包成一个change list,而不是零零散散的,不成系统的,不能独立运行的一堆代码。


再次检查,自己满意了,才会提交code review。一般,找同项目中的水平高的,能力强的,甚至技术leader,邀请他们来审查,他们能给你更好的建议,让你学到更多的东西,提高的更快。要求越高越严,实际对自己越好。有人经常犯的错误是找一个关系好的,或是很随和的容易通过的,去做自己的code review,以为这样省事,不会被“批评”,其实,从长远看是不利于自己发展和提高的。


作为代码审查者


跟高手交流的过程中,积累了不少code review的经验,自己也慢慢可以做一些code review的工作了。尤其是当别人改了自己写的代码,毋庸置疑会被挑选为第一代码审查者。




刚开始审查代码时,会偏重于表层的东西。整体扫描代码,代码风格是否满足,可读性怎么样,代码结构是否合理,是否有懒婆娘裹脚的函数,或是巨大的类,注释是否清楚,代码是否重复,是否完成了需求,是否有大的疏漏,等等。如果发现了这些相对容易识别的问题,会打回去,让作者先修改好,才给做仔细的深度的审查。原则上,如果代码提交者负责任的话,这类问题应该很少出现。


如果文档或是需求没有清楚说明,会和作者讨论,了解清楚要完成的任务,和解决办法,算法。所有这些都清楚了,就可以坐下来好好的读代码,想代码,审查代码了。




审查代码时,会一行一行读下来,理解它,会思考有没有一些可能出现的问题,边界情况是否考虑了。会思考如果自己来写,会怎么实现。如果想到的任何问题,会去检查测试用例中是否考虑到了。还会关注是否有安全漏洞,代码的扩展性如何,代码的执行效率如何,架构是否合理是否一脉相承,对象设计是否合理,在多线程多用户的情况下是否有问题,等等。很多的都可以作为checklist一项一项检查。


审查代码的过程,可不是一个轻松的过程。这时,不但在理解别人的代码,也是自己在思考如何实现。如果作者的设计和算法和自己不一致,会比较谁的方案更好。如果感觉自己的更好,会和作者讨论,建议。


代码复用,模式提炼是一个应该注意的点。看看代码的组织是否有利于别人复用,是否可以提取模式,能复用的应该提取出来生成便于复用的形式。再者,由于各人对整个代码库的掌握情况不一样,这时,也会关注作者的代码有没有是库里已经有的,那就应该调用,而不是重复实现,从而减少犯错。


对于重要的或是难以理解的代码,会做面对面的code review。对于核心或是critical代码,会组织code review meeting,大家一起看代码,这样,也是一个知识共享的过程。有时候,可能一个代码,会邀请多人审查,各人会有不懂的见解,发现不同的问题,虽然这样比较费时,但完成后更能保证质量。


作为管理者


后来,除了上面的角色,还要作为一个管理者,负责规范和实施code review。主要做着以下几个工作。


首先是制定公司的code review的规范和流程,而且这个必须作为研发的一项政策,要求全体研发必须严格执行。比如,类似如下的code review流程。




再者,文档化不同语言的代码风格(code style),对于公司常用的语言,都应该有一套,可能有Java,可能有C++,可能有Python,可能有PHP,可能还需要定义脚本语言的风格。这样,大家有据可循,统一思想和实践。


根据以前的经验,定义了一个code review的checklist,相当于一些注意事项都记载下来随时供参考,这样,对于主要的检查点,像安全检查,多任务多线程,扩展性,复用,OO设计,测试完备性,架构,等等,不会被忽略。其他的点,就可以自由控制和发挥了。比如,类似如下的checklist。




然后,设立简单易用的code review环境,并将review强制嵌入到代码提交到代码库的命令中。没有代码review,没有审查者的首肯,代码是没法commit到代码库中的。有人实现了review board + svn 的强制code review的方案,有人实现了 review board + git 的 方案。总之,希望在代码提交的命令中自动提醒和强制code review,这样人人都强制遵守,靠的是自动化的程序命令,而不是人。这一点很重要,能法制的,不要人治。




最后,量化效果,包括code review的执行情况,反馈时长,评论数量,反复次数,甚至和测试或是线上的bug系统联动起来,真正监控code review的质量,奖赏分明。各种指标可视化,放到dashboard上,谁都可以看到。再按指标给代码提交者和审查者排名,想激励优秀的,就将好的弄成 star list。想鞭策落后的,就将差的弄成 shame list。


这就是我的“code review”的成长历程。


喜欢的话,请关注我们的微信公众号“待字闺中”(daiziguizhongren)。


大家可能还感兴趣:



谢谢。

 
待字闺中 更多文章 【经典面试题】统计数组 【独家推荐】互联网产品和技术 【陈老师推荐】美国大数据工程师面试攻略 【Codeforces】24Game 【经典面试题】数字游戏
猜您喜欢 股市暴跌是一连串事件丨智谷趋势 国外读者是如何评价《三体》的? Swift,你不得不学的5个原因 Ansible常用模块总结 BDTC PPT集萃(五):大数据的挑战与前景