程序员对代码评审(Code Review)不可谓不熟悉,而代码评审也已经是许多组织的标准化实践。结合笔者的五年多的开发经验,既有经历过零CR的小组织,也有接触过完善CR规范的大厂团队。
对于“如何进行一次--高质量的组内代码CR”,结合最近和同事的讨论交流,包括我本人也有一些实践,在此跟大家一起分享下心得和体会。
我经历过怎么样的代码CR
我想起在2018年加入的一个小作坊团队,组内的后台开发一共才6个人(包括2个实习生),全部属于一个leader和一个骨干带飞所有人的情况。彼时,项目进度非常紧,几乎每个周6都要加班,我们用的代码托管工具还是SVN。当时最普遍的CR情况是:每个人提交代码时,都要口头通知一声leader,让技术负责人来过目一遍代码,并针对不合理的逻辑进行“友好的交流”。
2019年加入了一个更大点的团队(后台组有30个人),每个业务线都有小leader进行分管。彼时,开发内部用上了GitLab的私有化部署,工作节奏是周期性忙碌。当时最普遍的CR情况是:每个人可以直接合入代码到开发分支,同时每2周要对自己的代码进行一次线下的CR,邀请小leader和同事一起加入讨论。
2021年来了腾讯之后,才明白过去的组内CR在工具和维度上,都太过于“刀耕火种”了,并发现周围很多同事,都把性能和代码最佳实践挂在嘴边;在BG甚至部门级别,腾讯都养了一批专业搞研效的大佬在研究代码质量(我还好几次听过Google的专家讲“如何提交一次Commit”);而后经历“降本增效”大流行的阶段,在面临个人职业生涯存亡之际,内部的提CR的声浪肉眼可见的慢慢降低了。
此时,最普遍的CR情况是:需求评估(会议:研发+产品)->方案评估(会议:研发)->开发质量评估(会议:开发+测试)->上线评估(会议:研发+DBA+测试+产品)->功能验收(会议:产品)。
是的,这时候的CR更像是泛CR的概念,代码合入并不是一次CR的终点。同时,每个环节都有专门的平台工具来监控进度(eg,需求管理平台、代码管理平台、缺陷管理平台、流水线发布平台等),也算是把流程化做到极致了。
如何进行一次高质量的组内CR?
上面提到了3种类型公司的CR环境:有小作坊开发模式,有中型团队的敏捷开发协作,也有大厂标准化流程。
那么,是不是说一定是大厂标准化流程就是最好的呢?
我觉得非也;大公司固然有标准化,但标准化也意味着会逐渐形成一种“政治正确”,如果遇到工期紧的时候(相信我,大业务团队迫切需要的不是严丝合缝的CR,是高效发布以变现的时间),这种标准化过程到最后就是走个过场而已。
那么,是不是说小作坊就不具备进行CR的土壤环境?
我觉得未必,因为技术是相通的,需求是类似的,只是实现不同罢了,同时CR是个向组内同事学习的好机会。
关于CR:5W1H
CR前期准备
CR中期讨论
CR后期改进
CR的“长寿”秘诀
还是那句话,我们得有真本事,才能厚积薄发。自己写代码多了,其实也就很懂自己,哪些地方容易被别人挑刺了。
下面我就从五个方面(代码规范、代码性能、代码安全、代码合规、CR度量)说明下,有这些途径可以让CR变得更好。
代码规范
winter
一文读懂《Effective Java》第3条:用私有构造器或者枚举类型强化Singleton属性
一文读懂《Effective Java》第4条:通过私有构造器来强化工具类不可实例化的能力
一文读懂《Effective Java》第5条:避免创建不必要的对象 & 性能优化
一文读懂《Effective Java》第6条:消除GC触及不到的过期对象引用
一文读懂《Effective Java》第7条:避免使用终结方法
一文读懂《Effective Java》第19条:接口只用于定义类型
一文读懂《Effective Java》第20条:类层次优于标签类
一文读懂《Effective Java》第23条:不要在新代码中使用原生态类型
一文读懂《Effective Java》第24条:合理使用@SuppressWarining消除非受检警告
一文读懂《Effective Java》第42条:慎用可变参数
一文读懂《Effective Java》第43条:返回零长度的数组或集合,而不是null
一文读懂《Effective Java》第48条:如果需要精确答案,请避免使用float和double
一文读懂《Effective Java》第52条:通过接口引用对象
一文读懂《Effective Java》第53条:接口优先于反射机制
一文读懂《Effective Java》第54条:谨慎的使用本地方法
代码性能
真实的基础设施是非常多元复杂的,我们往往需要一个可观测性整体的标准定义。这就引入了一个概念:应用性能观测。
应用性能观测(Application Performance Monitoring),通常简写为APM。我们很难找到一个官方的定义去描述什么是一个应用性能观测软件。但在分布式微服务盛行于后台的今天,在这个领域里应用性能观测通常指用来观测系统的可用性,链路追踪、接口耗时、关键指标等信息的组件。
总结:通过完善应用层面的trace,metrics,logs三个父母,即可实现分布式应用的可观测性指标记录。实际上,也确实有很多非常优秀的开源组件给我们使用了,比如:ELK、SkyWalking等,如果你公司的应用是部署在腾讯云或者阿里云,更可以直接使用腾讯云APM和阿里云ARMS。
代码安全
安全类问题往往隐藏在缺乏安全意识的编码逻辑和未经检测或维护的开源依赖组件中,难以在日常开发和代码评审中被及时察觉。
而互联网大厂往往内部会有专门部门来负责代码安全扫描;也有开源的安全规范,比如腾讯语言安全规范:https://github.com/Tencent/secguide
代码合规
我们编写的“源代码”是公司的核心竞争力以及核心财产之一,其商业价值及对公司的意义不言而喻。因此如何合规地使用源代码对公司、对个人都尤为重要。
在法律上,源代码属于计算机软件作品一部分,可受著作权法保护。同时代码作为商业秘密,受反不正当竞争法保护。源代码的泄露或不规范使用,可能会给相关业务及整个公司带来损失,同时相关个人可能也会涉嫌触发公司高压线面临公司相应处罚,甚至承担相应法律责任。
另外,使用开源组件势必引入未知漏洞风险,比如2021年在安全圈里堪称核爆级事件的Log4j漏洞。
我接触过的几款代码合规检测软件分别是国外的Black Duck(黑鸭),国内的清源(CleanSource) SCA。
CR度量
代码评审活动开展程度需要量化数据做参考,腾讯代码管理平台提供了代码评审开展的原始数据,然后按需做进一步分析。其中,最重要的就是代码评审指标体系建立。
代码评审指标体系构建思路
详细指标描述:
参考文章: