【翻译】Tricorder-谷歌如何建立程序分析的生态系统

I. 介绍II. 背景A. 开发流程B. 谷歌的程序分析III. 谷歌程序分析理念A. 0误报率B. 授权用户做出贡献C. 改进数据驱动的可用性D. 工作流集成是关键E. 项目级别定制，而不是用户定制IV. 实现A. 架构B. 插件模型C. 分析器D. 修复E. 反馈V. 成果a)可用性:b)代码库影响:c)扩展性:d)可伸缩性:VI.相关工作VII. 探讨VIII. 致谢引用

译者的话

    许多公司痛苦于将如何将SDL落地到企业开发流程中，而代码审计的环节相对容易实践起来。在对标学习期间顺手翻译了这篇google的最佳实践，当然Google、Netflix、SAP、salesfore、Amazon这类公司不会称其为SDLC,使用了DevSecOps的方法论这种说法，推行起来对于人员要求也较高，但是面临着行业的痛点是共性。知易行难，大家可以参考指标以避免走弯路，去做正确的事情。
其他关联阅读资料：

• * [为什么Google上十亿行代码都放在同一个仓库里?](https://zhuanlan.zhihu.com/p/28524745)

• * [Google 如何建立程序分析生态系统](https://wenku.baidu.com/view/067d99eea0c7aa00b52acfc789eb172ded639975.html) 

原文链接：

[Tricorder: Building a Program Analysis Ecosystem](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43322.pdf) 

以下是正文：

    简介-静态分析工具帮助开发人员发现bug，提高代码可读性，并确保整个项目的风格一致。然而当扩展到大型代码库时，这些工具之间很难相互顺利集成进入开发流程中。我们提出了一个程序分析平台TRICORDER，旨在围绕程序分析构建一个数据驱动的生态系统。我们为我们的程序分析工具提供了一套指导原则，并为实现这些原则的分析平台提供了可伸缩的架构。我们对Google开发人员所使用的工具在实际的落地到生产系统进行验证，以显示出该平台的实用性和影响力。

I. 介绍

    静态分析工具提供了一种很有前瞻性的方法，可以在程序的bug出现在生产系统之前找到它们。开发者可以在源代码上运行分析程序来发现问题，甚至在合入代码之前也可以。虽然对静态分析工具[3]、[14]、[16]等已有了详尽的研究，但这些工具在实际应用中往往没有得到有效的落地。误报率高、输出混乱、与开发流程的整合性差，这些都导致了在日常开发活动[23]、[27]中缺乏使用。
    除了发现bug之外，工具还必须考虑到开发人员对[26]时间的紧迫要求。任何由自动化工具产生的中断输出都会迫使开发人员从主要目标[27]停顿下来。成功的静态分析工具可以增加高价值，同时最大限度地减少对已经很繁忙的软件工程师的干扰。
    我们过去使用静态分析工具的经验还表明，其中许多工具无法扩展到谷歌规模的代码库。分析不能假定它们可以访问整个源存储库或所有编译结果;单个机器的数据太多了。 因此，分析必须是可分片的，并且能够作为分布式计算的一部分运行，只包含部分信息。判断分析必须非常快，并在几分钟内提供结果。在我们之前在谷歌的经验中，现有的分析平台无法以这种方式扩展伸缩。
    我们还发现现有的平台和工具没有足够的可扩展性。谷歌有许多专门的框架和语言，理想的系统应该为所有这些框架和语言提供静态分析。我们理想的系统将允许领域专家编写自己的分析，而无需承担构建或维护整个端到端环节的成本。例如，编写c++库的团队可以编写检查，以确保开发人员正确使用这些库，而不必担心运行大型生产系统所固有的问题。
    在谷歌上试错了各种商业和开源程序分析工具之后(有关更多细节，请参阅第二部分)，我们一再遇到工具可伸缩性或可用性方面的问题。基于这些经验教训，我们想创建一个静态分析平台，它将:
•开发人员广泛而积极地使用它来修复代码中的问题，而不需要得到一小群拥护者或管理层的鼓励。
•顺利地集成到现有的软件开发流程中。
•扩展到海量代码库规模。
•使开发人员，甚至非软件分析专家能够编写和部署他们自己的静态分析规则。
    在本文中，我们介绍了TRICORDER，一个程序分析平台，旨在围绕静态分析构建数据驱动的生态系统。TRICORDER将静态分析集成到谷歌开发人员的工作流程中，在开发人员和分析器编写人员之间提供反馈循环，并简化了分析工具发现的修复问题。为了实现这一点，TRICORDER利用微服务体系结构来扩展到谷歌的代码库，并且每天生成大约93,000个分析结果。除了开发平台的开源版本之外，一个由2-3人组成的小团队维护着TRICORDER及其周围的生态系统[35]。TRICORDER的插件模型允许整个公司的团队成员加入Google的程序分析社区
    本文的贡献包括:
•一套指导原则，使谷歌的程序分析平台获得成功，得到广泛应用。(第三节)
•程序分析平台的可扩展架构。该平台通过工作流程集成，支持贡献者，响应反馈和自动修复来构建程序分析生态系统。(第四节)
•基于开发人员在正常工作流程中对分析的响应，对平台的效用进行实证和现场验证。(第五部分)

II. 背景

A. 开发流程

    在谷歌中，大多数工程师都在一个非常大的代码库中工作，在这个代码库中，大多数软件开发都是在head里进行的。在谷歌，每个工作日，工程师执行超过800k构建，运行100万个测试用例，生成2PB的构建输出，并发送30k变更列表快照(patch diffs)供评审。
    大型代码库有很多好处，包括代码复用的易用性和以原子粒度地进行大规模重构的能力。由于代码复用很常见，大多数代码依赖于一组核心库，对这些基本库进行更改可能会影响许多项目。为了确保变更不会破坏其他项目，谷歌拥有强大的测试文化，并由持续测试基础设施[43]、[15]为后盾。
    谷歌工程师使用标准化的分布式构建系统从源代码[20]生成独立构建。一组专门的工程师集中维护这个基础设施，提供了一个插入分析工具的通用配置。因为谷歌工程师使用相同的分布式构建环境，所以他们可以使用自己选择的编辑器。编辑器的选择包括但不限于Eclipse、IntelliJ、emacs和vim[38]。作为一种强大的代码评审文化的一部分，每一个新的补丁，称为变更列表，在签入之前都会由其他人的人来评审。工程师使用类似Gerrit[19]的内部代码审查工具执行这些审查。此工具提供了对代码行进行注释，回复现有注释，上载正在审阅的代码（作者）的新快照以及批准更改列表（审阅者）的功能。
    繁忙的工程师测试(并分析)他们自己的代码，而不是使用单独的QA流程。这意味着分析结果必须以工程师为目标，并且这些工程师必须易于运行和响应分析程序。因为大多数要发布的代码都是服务器代码，所以推出新版本的成本非常低，使得在代码发布后修复bug相对容易。

B. 谷歌的程序分析

    为了将程序分析工具集成到谷歌开发工作流中，已经进行了几次尝试。特别是findbugs[18]在谷歌[5]、[3]、[4]以及Coverity[12]、Klocwork[24]、故障预测[28]等分析工具上都有很长的实验历史。由于工作流集成、可伸缩性和误报方面的问题，所有这些工具在很大程度上已经不再使用。有些工具显示结果太迟，使得开发人员在提交代码后不太可能修复问题。另一些人过早地显示结果，而开发人员仍然在编辑器中使用他们的代码。基于编辑器的工具也遇到了扩展问题:它们对交互使用的延迟需求无法跟上代码库的大小。几乎所有的工具都必须作为一个独立的步骤来运行，并且很难与标准编译器工具链集成。我们一再发现，当开发人员必须导航到仪表板或运行独立的命令行工具时，分析使用率就会下降。
    即使在开发人员运行这些工具时，它们也常常产生很高的误报率和无法执行的结果[28]。这些经验与之前的研究一致，说明了为什么开发人员不使用静态分析工具[23]。最后，很少有开发人员使用我们之前试验过的任何工具，甚至在最引人注目的分析中-FindBugs，这个命令行工具在2014年也只被35个开发人员使用过(其中只有20个开发人员使用过一次)。我们之前确实在代码评审[3]中显示了FindBugs结果，但是这个尝试遇到了伸缩性问题(导致结果陈旧或延迟)，【译者注：关于这一篇，可以看到《【翻译】Google在构建静态代码分析工具方面的经验教训》】并且产生了许多开发人员不感兴趣的结果。相比之下，TRICORDER将成功作为标准开发流程的一部分。

III. 谷歌程序分析理念

A. 0误报率

    “0误报”可能有点夸张，但我们严格限制了允许分析产生的误报数量。误报对可用性和采用[8]、[23]、[33]都是不利的。
关于“误报”一词的确切含义存在分歧。对于分析者来说，误报是他们的分析工具产生的不正确的报告。然而，对于开发人员来说，任何他们不想看到[5]的报告都是误报。
    我们倾向于使用“有效误报率”这个术语来概括开发人员的观点。我们将有效的误报定义为来自工具的任何报告，其中用户选择不采取行动来解决该报告。作为一个例子，一些谷歌开发人员使用静态注释检查系统(例如用于数据竞争检测[34])。当一个注释检查工具正确地报告一个问题,它可能意味着有一个错误在源代码中(例如,变量实际上不受锁定保护),或者代码实际上是正常的但是注释集合不是足够详尽的工具。通常在程序分析研究中，后者不被认为是误报——开发人员需要向工具提供额外的信息。然而，一些开发人员认为这些问题是“误报”的，因为它们不代表代码[36]中的错误。
    相反，我们发现如果分析错误地报告错误，但是提出建议的修复将提高代码可读性，这不被视为误报。易读性和文档分析经常被开发人员所接受，特别是当他们提出改进建议时。值得注意的是，某些分析可能在理论上有错误的假设，但在实践中却没有。例如，只有当程序以不寻常的方式构建时，分析才可能具有误报，但实际上，从未见过这样的程序。这样的分析可能具有理论误报，但在具有严格执行的风格指南的环境中，它实际上将具有零误报。
    最重要的是，开发人员将决定分析工具是否具有高影响力，以及误报是什么。

B. 授权用户做出贡献

    在使用各种语言和自定义API的公司中ÿ