精神哥最近和团队中的开发同学聊天,看到很多开发同学对代码技能的提升都是有诉求的,只不过快速的业务节奏没有给他们太多停留的时间,在这种情况下如何给团队营造浓厚的工程师交流氛围呢?
方法有多种,目前最被认可或运用的方法莫过于CodeReview活动了。
那么 CodeReview到底能给团队带来什么?什么样的团队需要进行CodeReview活动?如何有效开展CodeReview活动?用哪种方式会比较好呢?
本周我们邀请到腾讯 MIG 无线研发部的刘永丽同学,分享她在CodeReview实践中总结出的宝贵经验。
笔者为了接地气地研究CodeReview实践,特选择了“手机管家高权限应用组”作为试点团队进行活动开展,这是一个对CodeReview活动非常认同并且愿意持续改进的团队,经过一年的运作,该团队CodeReview活动运作成效显著。
接下来笔者就根据试点经验,总结一下对CodeReview这个实践的看法和思考,希望能对想要或正在进行CodeReview活动的团队提供借鉴作用。
通过参与实战和团队成员讨论思考,我们认为CodeReview最终的作用将归到促进工程师日常代码交流和人员的成长上面来,与此同时作为辅助手段来对产品质量进行把关。
但一般来说,很多团队在CodeReview前期重点会是找问题(代码规范、潜在缺陷、BUG,代码设计等等),而后期随着问题的逐渐减少和习惯的逐步养成,工程师交流文化的营造将转化成重点,中期当有大批新人加入时,问题找茬将又上升为重点,如此复始。
总结一下,大多数情况下,找问题会是CodeReview活动启动的初衷,但越到后期它更大的意义将演变成工程师交流土壤的培育和人员成长的促进。
CodeReview作为业界公认的最佳实践,如果每个团队都能运用起来,固然是最好的,但是由于这项活动跟“人”这个因素密切挂钩,所以,它是否能有效运作跟团队状态、技术信仰和领导者诉求等都有莫大关系。今天,笔者想分享下个人在“到底什么样的团队需要”和“什么样的团队暂时不适合”这方面的思考。这里欢迎大家更多的交流讨论。
从代码质量提升的角度上看,以下类型的团队,笔者建议把CodeReview活动有效运作起来:
CodeReview活动跟人这个因素密切相关,从其带有的这个主观特点来说,笔者认为以下类型的团队暂时不适合开展CodeReview活动:
综上,笔者建议大家在考虑自身团队是否要推行CodeReview时,可结合团队实际状态进行综合考虑。但一般来说,如团队主观意愿没有问题,就可以大胆推行开展。
要想在团队内部有效运作CodeReview活动,必备四要素(如下图)。如果您的团队没有把CodeReview活动有效开展下去或者正深受烦恼,这部分内容希望您仔细看看。
如果一开始不定义好团队Coding标准,那在检视过程中就会存在两种情况:一种是各种不同的意见很难快速达成一致,影响review效率,另外一种是团队根本就不会重视代码规范的检视, 如果是前者还好,毕竟大家都还在关注什么写法是好的或对的这个问题,只要中途愿意建立起Coding规则,问题就能很快解决。而笔者跟进过的一个团队恰恰就出现了后者的情况:该团队由于前期没有明确Coding规则, 过程中大部分开发人员对规范类问题直接无视,CodeReview运作一段时间后代码中依然存在命名不规范,可读性较差等问题,直接影响了活动效果,这是我们非常不愿意看到的。
当然也有团队负责人说了,每天纠结于空格少了,行数字符多了等细节问题没意义啊,不想浪费这个时间,因此我们不需要代码规范。我个人不认同这个观点,因为代码规范并不只包括空格和字符等约束纬度,还包括了注释的要求,命名的规范,命名是否词能达意,代码结构安排等等影响代码可读性的因素, 如若这些方面连基本规则都没有,那一定会出现之前说的那两种情况(争议太多 or 完全忽视),效果可想而知。所以你可以根据自己的看法或需求做一定的规则定制,但不能没有Coding规则。
检视指南又名CodeReview-checklist。一个团队并不是所有人都是老司机,有很多同学是没有代码review经验的,他们往往不知道应该重点 check哪些点。
这个时候结合自身业务特点和团队之前踩过的坑,制定一个checklist是非常必要的:
这样可以让经验不足者在不知道要review什么时,能有的放矢,过程中逐步积累起经验。
以下是一个团队建立起检视指南前后,CodeReview发现问题数的变化,足见建立检视指南的重要性。
当然也有人说,我的团队代码检视都是让资深骨干做的,不存在不知道怎么review的情况。
但是我想说,骨干员工的时间毕竟很宝贵,他们也往往很忙碌,为什么不让更多的成员一起来参与review工作呢,毕竟CodeReview不仅仅是找茬,也是代码的交流和学习!
我们看到很多团队的CodeReview活动坚持不下来或逐步流于形式,其实最主要原因是过程中缺乏定期回顾和总结,从而不知道如何有效促进和帮助团队更好运作。
为了更好地促进这项活动,手机管家高权限应用组就专门成立了CodeReview组委会,这个组织每月都会对CodeReview运作状况进行总结,分析问题,解决问题,持续优化,其最后的效果能在团队内外均获得较高的认同度,可以说总结优化这个环节起到了非常关键的作用。
由于CodeReview本身跟人的经验或者意识都有很大关系,很多时候我们会为调动不起开发同学的积极性而烦恼,所以为了让大家更好的参与这个活动,我们一般都需要制定相应的激励机制。也有人说了,如果是leader强制跟考核挂钩,那就不需要这个东东了,嗯,但换个角度看,跟考核挂钩难道不是另外一种“激励”方式吗?哈哈。。。
激励机制的设立有很多种,一般来说,都是在定期回顾的基础上根据CodeReview的实际情况对表现积极的同学进行一定的礼品奖励(选择什么礼品,要看组织的经济状况,哈哈)。
笔者跟进的团队每月会从CodeReview提交次数和发现问题数等纬度进行质量之星选举,礼品包括了书籍,公仔,徽章等等,效果不错,做法供大家参考。
总之,代码规范、检视指南、总结优化和激励机制这四个因素对成功运作CodeReview活动都非常关键,但每一项里面的内容具体要如何定义,团队在参考业界做法的基础上可根据实际情况进行一定的定制。
目前业界运作CodeReview的方式有多种方式:强制&非强制、线上交流&线下会议、小片段&大模块、事前&事后、高频率&低频率,等等……据了解,目前每种形态都有各自的市场,被不同的团队运用着。
接下来笔者个人角度分析下各种形态的优缺点,供大家参考:
最后组合一下,笔者个人推荐的CodeReview方式是强制+事前+小片段+线上交流+高频率,同时,如果能结合线下的大模块方式开展代码交流活动,效果会更好,这个经验来自手机管家高权限应用组的接地气实践。
但是,团队状态不一样,选择方式允许有差异,所以具体选用哪种方式组合,还是要由团队自己作主。
为了让这篇文章能给读者带来一定帮助,笔者反复进行了review和相应的修改操作,且不论最终目的有没有达到,至少态度和行为上都已努力做到最好。
同样,笔者认为,开发编写的Code, 要想让别人更容易读得懂,一定也需要review才有可能达到目的。
所以,我们一起让CodeReview活动这股清流飞起来吧~
本文系腾讯Bugly独家内容,转载请在文章开头显眼处注明作者和出处“腾讯Bugly(http://bugly.qq.com)”