现有的静态代码扫描体系弱爆了？看看阿里的吧！

摘要：本文由淘宝技术部高级无线开发工程师详细剖析了手机淘宝的现状及挑战。针对手淘问题发现被动、感知模糊和缺乏经验积累等众多问题，阿里精心研发推出了定制化的移动静态代码扫描体系！那么该自行研发的扫描体系与已有的在线代码扫描工具相比有何优势呢？阿里将其应用于EMAS持续交付解决方案中，用数据说明实力！

本次直播视频精彩回顾， 戳这里！ 

演讲嘉宾简介：

芸墨（龚能）淘宝技术部，高级无线开发工程师。

以下内容根据演讲嘉宾视频分享以及PPT整理而成。

本文将围绕一下几个方面进行介绍：

1. 手机淘宝现状及挑战

2. 阿里巴巴移动静态代码扫描体系

3. EMAS持续交付解决方案

一． 手机淘宝现状

1. 研发支撑体系的演进

手机淘宝近十年的演进史可以分为以下阶段。阶段一：工具型APP。2008年手机淘宝的第一个版本正式上线发布，此阶段工作重点从商品体系展开，从商品搜索、进入商品详情、下单、支付直至订单生成，完成商品购买操作的闭环，使得应用功能和基本性能得到保障。阶段二：平台型APP。由于手机淘宝的业务得到不断发展，发布了2.0版本的平台型APP，也称为航母级APP。此时不仅仅需要关注淘宝相关业务，也需要关注集团中其他业务，例如聚划算、天猫、飞猪，都将相应的业务入口放在淘宝中。因此此阶段中淘宝每次的版本迭代涉及了众多人员和业务，工作量较大。这个过程中主要关注航母级平台的迭代效率及稳定性。阶段三：生态型超级APP。手机淘宝如今已经成为一个生态型的超级APP。在去年的双十一，阿里电商当天的GMV（Gross Merchandise Volume）达到了1670亿，一个非常庞大的规模。这意味着淘宝已不单单是一个入口，而是承载着阿里集团业务中轴的角色。除了阿里电商，阿里大文娱和金融体系都会通过淘宝进行协同工作，共同创造了这个了不起的业绩。在这些阶段发展过程中，淘宝的维护人员也从最初的几个人发展到如今的千人以上，旨在完成业务的创新以及阿里体系下生态的协同。

2. 手淘现状

在这样的大背景下，手淘采用了松耦合的架构体系，实现模块化开发和高铁式管理。高铁式管理原意是指任何购买了高铁票的乘客都是可以搭乘高铁的，在手淘中意味着所有业务只要完成了业务功能，就可以参与集成，但是需要达到一定的交付质量标准。因此这里提供了一整套的质量保障体系，快速保障交付物质量。集成的大版本发布上线后，仍然有一套监控体系，及时保障质量，跟进线上质量体系，同时也提供了动态化和热修复的能力。若某些业务完成功能开发后未能及时赶上集成，正如乘客购买了高铁票但没有赶上车，这种情况下提供了自主灰度和自主发布可供选择。

3. 面临的挑战

在手淘业务发展的过程中也面临了诸多挑战。首先，发现问题的过程有时是一个被动的过程。有些问题并不是在开发测试阶段就可以发现，而是在发布上线后通过监控体系发现。发现问题的时间较晚，需要被动追查问题，并且从问题的发现、定位到修复，时间周期长。第二个挑战是感知模糊。如何确认开发的应用质量达标，这并没有一个固定的标准。正如现在正火爆的区块链和数字货币，曾发生过一个数字货币的市场价值从60亿瞬间清零的事件，这是因为这个货币支持的智能合约的代码中有数据类型溢出的问题，这个漏洞被黑客发现了，因此伪造了大量的货币并在市场抛售，造成了该货币的市场价值瞬间清零。归根结底，这就是一行代码的bug带来的巨大的损失。类似的，在手淘的业务中，也存在这样不知不觉带着很严重的错误上线的情况，可能对系统的安全等性能造成巨大的威胁。第三个挑战是缺乏积累。手淘在每年双十一的体量特别大，这就意味着在双十一之前需要相当多的准备工作，例如需要组建一个专家组研究分析往年的双十一crash情况，力求减少crash，还有需要对性能问题进行梳理和优化。那么每年这些工作都需要重复进行，如何沉淀其中专家的经验来传递给下一次迭代的人员，没有很好的解决方案。其次由于人员众多，代码开发风格各不相同。在一个小团队中可以通过一个文档或定期的代码评审来保证代码风格的一致性。但在团队与团队之间甚至一个公司中，如何保证代码风格统一也成了一个棘手的问题。最后，线上问题的排查和解决也存在着大量的重复劳动。为了解决上述问题和调整，阿里研发推出了移动静态代码扫描体系。

二． 阿里巴巴移动静态代码扫描体系

1. 特点分析

该移动静态代码扫描体系有三大特点，一是横跨全研发流程。在创建产品时，该体系可以针对该产品或应用自定义规则的开启或关闭，及其优先级程度。产品开发过程中，可以定时触发扫描，与CI/CD流程结合。在产品提交集成时，如果存在一些严重的问题，例如威胁到系统稳定性和安全性，则不允许提交，必须消除bug改进后才可以允许提交参与集成。这种横跨了全研发流程的特点保障了产品质量的稳定可用。第二点是数据驱动。根据每天扫描的结果会生成质量大盘。质量大盘可以准确分析出业务质量情况、问题分布。最后针对阿里巴巴的研发经验以及crash分析，基于存在的性能、安全问题，将大量的开发经验沉淀成为规则库，将其与IDE插件和阿里平台结合。这些技术经验的积累可以帮助每个团队在发布之前提前对产品进行一次质量过滤。

2. 与其他工具的比较

那么为何不直接使用现有的一些免费开源的扫描工具？为何要自行开发一套移动静态代码扫描体系呢？现有的这些扫描工具大多具有以下几个特点：

1） 手段简单。绝大多数线上扫描工具仅仅是检查语法风格问题，但阿里作为一个企业级研发，需要可以发现潜在的bug。

2） 无约束力。它们只是一个单纯的工具，缺少明确的卡口机制，但阿里需要能和CI/CD结合在一起的技术服务。

3） 无数字化度量。作为一个开源工具，这些工具手段较为简单，发现问题的深度较浅，但企业研发过程中需要深入的分析问题并且生成数字化度量的必须指标。

4） 稳定性差。企业级研发通常需要面对上亿行代码的静态分析，因此这个扫描体系需要对性能和稳定性有很高的要求。

那么阿里自行研发的扫描体系与这些在线工具相比有什么优势呢？

1） 定制化。首先，阿里巴巴众多的研发经验都沉淀为规则库，例如阿里现已开源的安卓开发规范等，基于线上大数据分析crash的成因定制规则，包括安全、性能、稳定性、国际化、格式、正确性。

2） 解决方案。除了指出问题外，还需要指出如何解决。深入研发流程后，将研发经验沉淀为规则库，在线上发现问题后再次沉淀，形成闭环。此外，它可以提供平台和IDE插件。

3） 约束力强。整个过程中打包可以自动触发，不需要人工操作。如果发现问题，会将bug自动分发至各开发人员，改善过的bug会在晚上进行auto-fix，如果该问题没有解决，那么第二天上线后仍然会变成reopen状态。另外会将规则作为每个迭代的集成卡口。

4） 数据化。报表大盘可以跟踪集团所有客户端和每个业务模块的问题分布和趋势变化，形成对应的质量大盘。

5） 高稳定&低误报。与其他现有的扫描体系相比，该静态代码扫描体系有着较高的稳定性和较低的误报率。

6） 核心引擎：现主要支持AndroidScan\OSScan\WeexScan。Weex是阿里一款跨平台的动态解决方案。

 

3. 手淘静态代码扫描&CI/CD流程

该代码扫描体系与阿里的终端CI/CD流程结合形成质量闭环的示意图如下所示。

1） 自定义规则。结合线上crash、性能优化、安全问题、阿里巴巴无线编码规范、专家经验定制扫描规则。

2） 任务触发。通过IDE插件触发任务，定时构建任务和打包任务，在任务完成后将提取到的bug自动分配至相应的开发人员处理。

3） 数据大盘。每天的扫描结果可以生成质量大盘，问题的类型分布和规则分布会帮助业务开发人员量化分析代码情况，及时作出调整。

4） 集成卡口。集成时作为最后一道防线，保证集成发布的代码稳定可靠。

若上线后发现新问题，那么便继续定义新的规则，进行上述闭环操作。目前该静态代码扫描体系支持大多数核心业务，包括手机淘宝、飞猪、天猫、优酷、土豆、聚划算、咸鱼、钉钉、阿里健康、菜鸟裹裹、菜鸟驿站等。

4. 系统界面展示

系统中，每个客户端可以应用自定义通过标准，例如多少fatal和多少error可以为通过标准；在每个产品中，可以自定义开启的规则和等级，例如对淘宝某业务来说该规则无关紧要，那么便可以调低其优先级或者关闭，但对于聚划算某个业务来说非常重要，便可以调高优先级；项目构建后便自动触发任务执行；最后提交集成前，卡口生效，即上线前若该项标准没有达到定义的可通过级别，那么便不予上线。下图为提取出的问题列表，根据产品业务线搜索到对应的问题列表。在问题详情页会对每个问题有详细的描述，并且提供了bug转移和关闭的功能。

 

5. 规则和插件定制

规则定制有几大方向，包括语法错误、业务问题、性能问题、安全隐患、稳定性、测试全路径覆盖以及编码规范。例如在安卓中，通过URL导航进行跳转操作，这需要对该导航判断是否为标准格式，若不满足会出现UnsupportedOperationException异常，那么这里定制的规则会帮助判断是否满足格式条件。再如，安卓中希望子类调用父类方法CallSuper的annotation来提示时，则必须重写Super方法。若没有override，编译时不会报错，但运行时会出现SuperNotCalledException异常。因此，该问题也在规则定制中加以预防。此外，这里还实现了一个典型问题ConcurrentModificationException异常的处理。它是指在迭代器遍历Collection的时候，modCount和expectedModCount不同步。该问题在手淘中的crash多次出现，那么在其他中小型企业相信也有类似的问题。这里定制的规则会帮助开发者发现这类隐藏的问题。实现了这些规则后，通过IDE插件结合CI/CD流程进行扫描，操作过程详见大会视频。该静态代码扫描体系在阿里使用至今大约2年，在手淘中每天平均上报问题数为3000多，严重问题解决率100%，命中规则crash率降低30%。这只是手淘统计出的数据，加上支持的其他业务，扫描体系在阿里的承载的工作量是非常大的。

6. 总体架构图

上图为阿里持续集成体系的总体架构。该静态代码扫描体系在总体架构的基础设施中提供四大功能。扫描引擎中心提供基于安卓、IOS、Weex、Python、安全相关的扫描工作。算法中心提供相应的规则管理、模型训练、策略管理。规则配置中心实现卡口配置、权限配置、消息配置、审批配置。数据中心负责对扫描的结果进行数据分析统计，对上层业务进行服务。在研发支撑体系中，该静态代码扫描体系提供了集成管理等服务，为稳定性、性能、安全、通用性提供扫描支持。由此得到的数据为产品度量中心提供支撑。

三． EMAS

1. EMAS持续交付解决方案

上述扫描体系及持续集成相关功能都在EMAS持续交付解决方案中得到承载，然后阿里将EMAS赋能给商家，希望可以开放阿里巴巴的研发经验给社区。现在EMAS支持三种研发模式：传统的Native开发方式、跨平台的Weex开发、Native和Weex混合开发。并且希望通过EMAS提供三项IT效能指标参考体系：研发团队的研发效率、应用质量的标准以及应用性能标准。同时EMAS也覆盖了五大持续交付职能域，从研发阶段、测试阶段，到发布阶段、运维阶段、运营阶段，都提供了工具和基础服务。具体每个阶段提供的工具与能力见下图所示：

2. EMAS移动研发全景赋能

阿里希望通过EMAS从团队和业务两方面提升业务能力。在团队方面，希望可以将阿里巴巴内部沉淀的标准赋能给企业，将系统化的工作流和方法论、工程研发理念提供给社区，为用户提升团队的人均效能，提高协同效率与工程效能，升级组织架构。在业务方面，希望可以提供完善的基础设施、优雅的业务架构与顶层设计等。最终是希望将阿里的架构能力开放给社区，让用户获得更高可用的底层架构。

本文由云栖志愿小组郭雪整理，编辑百见