《google如何建立程序分析生态系统》由会员分享，可在线阅读，更多相关《google如何建立程序分析生态系统（40页珍藏版）》请在金锄头文库上搜索。
1、Google 如何 建立程序分析生态系统,2018/9/30,Agenda,程序分析存在的问题 项目的目标 Google的背景 Google的程序分析理论 项目的实施 思考Reference Tricorder: Building a Program Analysis Ecosystem,Page 2,程序员已经很忙了 工具必须非常重视是否让开发人员花费更多额外的时间来处理工具的结果； 任何自动工具的输出都会使开发人员从原来的开发思考停顿下来； 好的工具应该给尽量少的打扰开发人员，并为开发人员带来更多的附加值； 工具的问题 High false positive rates(高误报率） Con
2、fusing output（令人费解的输出报告） Poor integration into the developersworkflow(不能很好的融合到程序员的日常的开发流程中） 平台扩展的问题 Google存在不同的框架和开发语言； 一个理想的平台能够适应这些需求 能够让各领域的专家来编写自己的检查工具，而不需要额外的应用成本； Google的业务需求 不能满足google巨大代码量的需求，一个完整的编译过程是无法用一台机器完成的； 分析必须能够被拆分（shared)，并且能够分析拆分的信息，得到这部分的结果。 分块的分析必须能够在极短的时间内完成，在几分钟内得到结果；,静态分析存在的问
3、题,Page 3,能够普遍地、积极地、主动地被程序员用来修复程序中存在的问题（be widely and actively used by developers to fix problems in their code, without prompting from a small group of advocates or management);无缝地整合到现有的开发流程中（ integrate smoothly into the existing developer workflow);能够度量所有的代码(scale to the size of an industrial codeb
4、ase);授权给开发者(甚至他们不是分析专家),让他们自己能够编写他们自己的检查规则(empower developers, even non-analysis experts, to write and deploy their own static analyses).,理想的静态分析平台,Page 4,Agenda,程序分析存在的问题 项目的目标 Google的背景 Google的程序分析理论 项目的实施 思考Reference Tricorder: Building a Program Analysis Ecosystem,Page 5,项目目标,We present TRICORDE
5、R,a program analysis platform aimed at building a data-driven ecosystem around program analysis. We present a set of guiding principles for our program analysis tools and a scalable architecture for an analysis platform implementing these principles. We include an empirical, in-situ evaluation of th
6、e tool as it is used by developers across Google that shows the usefulness and impact of the platform. TRICORDER 构建一个围绕程序分析,以数据驱动的程序分析平台； 建立一套程序分析工具的应用规则； 平台通过度量（使用、效果）方式实施这些规则，并与开发流程融合。通过建立一个在开发程序员和规则开发者之间的闭环的反馈系统，来完成问题的反馈、自动修复（部分）； 一个建立在程序员在开发流程中应用工具的具体信息数据来度量的平台； 一个以微服务构建的适用google的代码项目规模的平台。每天会产生
7、9,3000的扫描报告，但仅由2-3人维护的系统；,Page 6,Page 7,息处理类： 可以无线下载目标终端的数据。包括非星联系统，并且可以处理和分析数据。三录仪也可以作为一个数据终端，多台可以联网处理数据。 扫描器类： 通过扫描波束来确定目标的介质，化学成分等，也可以扫描周围的空间组成，探测此范围内的生命信号，以及对目标物体成像，医用的CT等。 工程技术类： 可以通过扫描来诊断设备的故障。并且优化显示故障排除方法。,TRICORDER 是一种手持式的多用途仪器。它是星际旅行里经常要用到的一种必备仪器。,http:/fsd.trekships.org/operations/tricorde
8、r.html,The tricorder of 2266 was a compact instrument that featured scanning, recording, and computing technology.,Star trek星际迷航,星际迷航中的科技：平板电脑（PAAD）、GPS、大显示屏、宇宙翻译机、自动门、手机、传送器、复制机、全息技术、曲速旅行、视屏会议等等。,史蒂芬霍金 年果壳中的宇宙 即使把我关在果壳之中,仍然自以为无限宇宙之王,Agenda,程序分析存在的问题 项目的目标 Google的背景 Google的程序分析理论 项目的实施 思考Reference T
9、ricorder: Building a Program Analysis Ecosystem,Page 8,许多工程师都是在一个很大的代码库上进行开发的 perform more than 800k builds, run 100M test cases, produce 2PB of build outputs, and send 30k changelist snapshots (patch diffs) for review 大代码库使代码重用和重构变得非常容易和普遍； Google 有极强的整合测试的测试文化(Google has a strong testing culture b
10、acked by continuous testing infrastructure) Google 采用一套统一的标准的构建和发布系统(Google engineers use a standardized, distributed build system to produce hermetic builds from source code); 统一的构建系统为代码分析提供了统一的接入点 Google有极强的代码审视文化 每一个Changelist都会被在checked-in之前被审视,Google的开发特点,Page 9,要求开发人员能够方便的运行分析工具，能够快速地得到结果,Goog
11、le的Codereview工具类似gerrit,Page 10,https:/bugs.chromium.org/p/gerrit/issues/list,provides the ability to comment on lines of code, reply to existing comments, upload new snapshots of the code being reviewed (author), approve the changelist (reviewer).,Google曾经尝试过将以下工具整合到开发流程中 Find-Bugs，Coverity，Klocwor
12、k，缺陷预测理论(fault prediction) 这些工具存在的问题 与工作流程的整合 太晚：只有在提交代码之后才能得到结果 太早：开发人员还在调试代码的时候就出现了 几乎都需要运行单独的命令，不能与编译器整合在一起 扫描的规模。这个问题在桌面工具有为突出 高误报率 结论 当工具有单独的命令或即使通过仪表盘来运行的时候，使用量会慢慢减少,Google的程序分析,Page 11,Agenda,程序分析存在的问题 项目的目标 Google的背景 Google的程序分析理论 项目的实施 思考Reference Tricorder: Building a Program Analysis Ecos
13、ystem,Page 12,没有误报(No false positives) 研究表明误报是程序员不愿意采用分析工具去发现bug的主要原因之一 Google理解为有效的误报率(effective false positive) 标示工具不确定的告警（这类问题往往是因为工具得到的信息不足） 能提高代码可读性的缺陷，不被认为是误报； 不过度分析，不考虑实际中不会出现的情景(theoretical false positives),Google的程序分析理论没有误报,Page 13,让开发人员来决定工具的作用和误报率 developers will decide whether an analysi
14、s tool has high impact, and what a false positive is.,Google的程序分析理论用户参与,Page 14,用户参与(Empower users to contribute) 只有用户自己最了解自己的项目，让他们自己来写规则，并对结果负责； 这些领域的专业人员并不了解如何和流程的整合，这也是平台的作用； 为了保证质量我们和开发规则人员约定规则下线条款： 没有人使用这个检查(No one is fixing bugs filed against the analyzer.) 资源的使用影响了系统(Resource usage (e.g. CPU
15、/disk/memory) is affecting TRICORDER performance) 分析报告让开发人员困惑(The analyzer results are annoying developers),经验表明自豪感会让规则的开发者有着强烈的主动性去避免规则下线。,Google的程序分析理论数据提高可用性,Page 15,数据提高可用性(Make data-driven usability improvements) 问题响应非常重要。 程序员和工具建立信任关系，这种信任会因为对报告的不理解迅速减低； 一款工具的bug在改进了用词或连接到了帮助文档后，75%被修复； 建立一个反馈
16、系统能很好的提升工具的可用性；,Google的程序分析理论工作流整合是关键,Page 16,工作流整合是关键(Workflow integration is key) 与工作流整合是提高工具的效果的关键因素； 工具的触发最好由： 编辑代码editing code, 运行编译running a build, 创建或更新修改表 creating/updating a changelist, 提交一个更新表submitting a changelist. 扫描的报告最好在提交代码之前得到 一个调查表明程序员期望在编译时就得到检查报告的人数是在提交修改列表时的两倍； 在编译时检查，就要求有效的误报率要几乎等于，最高不超过%,Tricorder与工作流的整合,Page 17,编译器,分析工具,与编译告警一起送给开发者,提交代码 审核,分析工具,一起送给代码审计者,要求：速度快，误报5%,要求：5-10分钟，误报10%,开发流程,审计流程,修改代码,IDE,本地分析 工具,远端分析 工具,每日构建,分析工具,分析报告,专职团对专职处理,Tricorder,
