51Testing软件测试论坛

标题: 如何做好研发代码质量管理？看这篇实战内容即可！ [打印本页]

作者: lsekfe 时间: 2022-9-8 13:12
标题: 如何做好研发代码质量管理？看这篇实战内容即可！
摘要：如何高质量快速交付研发产品是每一位技术研发永恒追求的目标，如何在快速迭代发布下保障研发产品质量是每一位技术研发要共同思考的问题。
　　在“安卓巴士全球开发者论坛·北京站”会议上，TalkingData SDK技术研发经理韩广利做了题为《研发代码质量管理最佳实践》的主题分享，将TalkingData SDK完整的质量保障体系的创建过程和最佳实践分享给所有开发者，希望能够对大家有帮助和借鉴。
　　以下是韩广利的分享精粹：
　　在演讲之初，韩广利首先分析了移动端平台发展趋势，包括以下三个方向：
　　首先，双卡是移动端平台的主要趋势，今年9月发布的iPhone最新机型已经支持了双卡，这对于市场将起到很大的驱动作用。
　　其次，由于人工智能的不断演进，两大平台也不断对其进行技术跟进，比如安卓平台的TensorFlow，以及iOS平台的CoreML。
　　第三，用户隐私政策会越来越严格，不仅用户自身非常重视隐私，国家相关法规也日益完善，移动端平台的行为权限将逐步受到严格约束。
　　TalkingData基于相关政策为不同平台提供相应的适配和支持，也正因如此，就需要一个良好的代码质量管理体系去保证TalkingData SDK的质量和稳定性。
　　回顾TalkingData SDK整体架构的演进史，可以简单分为三个阶段：
　　·简单分层：只支持一条业务线；
　　· 多服务：满足不同业务线逐渐增加的需求；
　　· 微服务&模块化：满足不同开发者打包定制化的需求。
　　在功能叠加的过程中，需要对代码架构进行调整，那么此时应该思考两个问题：架构调整的原因什么？调整的目标是什么？
　　带着这两个问题，韩广利从四个部分进行了阐述。
　　代码分支管理
　　当代码分支不断增加，现有的人力和技术框架将无法支持功能的快速迭代。即便在某一个分支上解决了bug，但还需根据不同的场景将其添加到不同的分支上，分支的代码就会产生很大的差异，又需要投入更多的精力和时间去解决相关问题。
　　为此，TalkingData SDK进行了改造，将分支分为：对外发布交付分支、开发测试分支、以及个人创建分支。同时，也对原有的直接拉取分支的原因进行了一些反思：在架构设计之初，代码之间的耦合性较强，同时没有从业务或数据角度去进行独立设计，在打包的参数上没有进行动态配置。
　　为了改变现状，TalkingData制定了三个目标，一是改变模块之间的通讯方式；二是重新设计代码功能模块；三是约束代码之间的边界，尽量消除耦合性。
[attach]142657[/attach]
解决方案主要采用了微服务的思想——服务之间相互独立，随意调用或组合；对功能模块和数据模块进行了拆分；改变通讯方式做到解耦的效果，又将动态的配置参数分离出来，实现了支持多条业务线，并且可以满足定制化的需求。
　　在打包上进行了标签化的管理，同时配合标签检查脚本，达到定制化勾选和服务的打包功能。
　　韩广利表示，在架构重构时，需要进行一些取舍和选择，其核心思想是：架构在于目的而非框架，因为架构最终是要服务于业务的。他还提供了5大原则作为参考：
　　· 独立于框架
　　· 可测试性
　　· 独立于UI
　　· 独立于数据库
　　· 独立于任何外部代理
　　而在选择架构时应从易于维护、易于测试、内聚以及最核心的解耦出发，要让模块之间互相独立。
　　SDK功能打包管理
　　TalkingData SDK提供不同业务线打包的定制化开发需求。在庞大的体量中，如何保证打包的功能正常、方便测试？为此，在设计目标当中加入了分层的考量，首先是用户输入信息：邮箱、业务线以及所需平台，然后是整个平台的业务处理、输出的用户申请功能包，最后通过邮件发送给申请的开发者。
　　逻辑流程如下图：
[attach]142658[/attach]
在打包管理中，比较常用的工具有 GitLab、Jenkins、Server。
　　代码review规则及流程
　　在代码review中设置人为检查和脚本检查两种机制。
　　在人为检查中，负责review的人员必须要参与最初的需求和设计的审核，不仅要了解整个功能需求的细节，还需要对功能或测试负责，撰写review checklist，最后要交付review 模板，在出现问题时可以进行问题追踪。
　　在脚本检查中，需要进行编译和制定代码规范、静态代码检查，以及安全漏洞等方面的工作。
　　以上两种机制可以让代码review真正起到作用，而避免沦为形式化流程。
　　TalkingData SDK在代码review时有几种方式：
　　· 1对1：改动较小的bug、需求和优化
　　· 1对多：改动较大的bug、需求和优化
　　与其他公司选用技术主管或特定人员作为代码review人员不同的是，TalkingData SDK 的代码review主要由组内成员相互之间进行，这样对于个人的技术和框架理解会有所帮助。
　　代码review模板主要有三个部分：谁做的review？发现了什么问题？如何解决整个问题？好的代码review模板要做到问题可记录、问题可追踪。
　　代码质量管理的工具
　　在代码质量管理的流程中，TalkingData SDK在代码托管上使用了GitLab，在项目管理上使用了JIRA。之所以选择这两个工具是因为两者可以互相打通，方便后续在遇到问题时可以根据记录进行排查。
　　研发流程如下图：
[attach]142659[/attach]
其中，单元测试在研发中是非常重要的，开发者写完一个功能模块的主流程通常没有问题，可以做到自测；但是分支的一些处理流程，即便交给测试人员也很难测试出来。因此单元测试就显得尤为重要，它可以覆盖很多异常分支，所输入的条件在参数当中可以动态设置。
QA测试流程如下图：
[attach]142660[/attach]
在前期，会由研发和QA整理一些测试用例，分为高中低等不同的级别，研发在提测时会有测试通过率，以保证测试的效率。
　　另外，TalkingData SDK 在上线后也需要去做一些监测，比如交付质量、对不需要功能做删减、打包的完整性等等。
　　总体来说，即采用微服务的思想，尽量让功能模块化管理，利用工具管理流程，进行单元测试，同时上线前后都要设置一些检查策略，做到万无一失。
　　最后，韩广利表示，流程并非形式，需要真正地落地执行，长此以往，就会对效率有很大地提升。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)