Kythe-An Overview of Kythe Kythe概述
An Overview of Kythe
Introduction to Kythe
Kythe项目的建立是为了提供和支持工具和标准，以鼓励操作源代码的程序之间的互操作性。
在较高的层次上，Kythe的主要目标是提供一种标准的、与语言无关的交换机制，允许在源代码上操作的工具彼此顺利地共享信息。
该工具包括 构建系统、编译器、解释器、静态分析、编辑器、代码审查应用程序等
本文档的其余部分对Kythe背后的思想和基本原理进行了基本介绍，并提供了有关该项目的其他更具体文档的链接。
Background
随着软件项目规模和范围的增长，开发人员越来越依赖工具来执行日常任务，
如构建、测试、部署、调试、重构和分析源代码。
工具链常常包含多种语言、各种源代码控制系统、各种构建和部署工具、测试框架，甚至还要大量拼凑在一起的脚本，
即使对于像初创公司的小型开发团队来说，这样的工具链 用于编写、测试和部署代码时也可能相当复杂。
当代码库很小并且依赖关系很少时，手动执行这些任务相当容易：几千个文件的小代码库可以导入到IDE中并直接操作。
然而，随着代码库的增长，它越来越依赖于外部（“第三方”）库和工具。
此外，随着开发人员团队的成长，在单个工作站上高效地构建、调试和测试项目 是困难(甚至不可能的)。
Kythe源于Google庞大的多语言内部代码库创建大规模交叉引用语义索引的经验。
我们发现，工程师经常浪费大量时间来调整新工具以适应他们的项目，并在此过程中重新发明解决方案来解决其他程序（例如，编译器或IDE中嵌入的分析工具）已经解决的问题。
发生这种情况的主要原因是现有的解决方案通常不能很好地与开发人员正在使用的其他工具配合使用。
一些团队通过强迫每个人使用相同的工具来“解决”这个问题，但根据我们的经验，这种方法的可伸缩性很差：集成环境对于集成的语言和工具来说工作得很好，但添加新部分的成本很高。
开发人员的工具偏好是高度多样化和特殊的，当开发人员被迫使用他们不喜欢的工具时，他们的工作效率会急剧下降。
因此，Kythe的主要前提是，编程语言工具应该能够轻松地相互通信：不仅是给定语言的工具，而且是项目中使用的所有语言——不仅是单个选定的开发环境，而且（可能）是开发人员可能使用的任何可行的工具组合。
考虑到编辑器、编译器、构建系统、分析工具、部署、测试、持续集成——其中每一个都有很多选项，但目前在实践中真正能很好地一起工作的组合相对较少。
Goals of Kythe
将Kythe视为连接各种语言、客户端和构建系统的工具的“中心”的最佳方式。
通过定义与语言无关的协议和数据格式来表示、访问和查询作为数据的源代码信息，Kythe允许将语言分析和索引作为服务运行。
这反过来又支持分析工具与客户端工具（如编辑器、IDE和代码浏览器）的轻量级（“瘦”）组合。
中心辐射型模型将集成L语言、C客户端和B构建系统的总体工作从最坏情况下的O（L×C×B）（生态系统大小的组合）减少到O（L+C+B）：实现给定编译器的兼容性。
对于每个组件来说，编辑器或构建系统大致是一个固定的前期成本，之后该组件可以直接与所有现有组件互操作。
为了使该模型工作，Kythe提供了一个语言不可知的图形结构来捕获构建系统和编译器元数据，以及关于源代码的语义信息，如交叉引用（例如，定义及其用法、类型信息和跨语言关联）。
通过设计，Kythe图模式是自由和可扩展的-我们已经定义了许多有用的子图，但新的节点和边类型是结构化的，以便可以轻松地扩展图，而无需求助于中央机构。
Kythe的基本设计原则之一是互操作性不应该是“全有或全无”：工具应该优雅地调整缺失或不完整的数据。
在很多情况下，我们发现有信息总比没有好。同时，宁可发出不完整的数据，也不要发出不正确的数据。
在实践中，重要的一点是，工具不应在数据不完整的情况下“放弃”，因为部分结果通常仍然有用。
Non-goals of Kythe
尽管Kythe提供了以互操作性等众多目的，但它并不涵盖所有可能的情况。
基于设计，在这个项目中我们不试图解决以下目标：
- 编写编译器或优化器
Kythe’s graph为了在多种语言中捕获具有相似特征的高级交叉信息。
底层细节（如代码生成和优化）本质上是特定于语言的。
虽然原则上可以在Kythe’s graph中对编译器的内部结构进行建模，但这并不是主要目标。 - 替换已经存在的IRs
一些工具（例如，静态分析器）已经为代码提供了富有表现力的专用内部表示。
Kythe并不是此类IRs的通用替代品，
相反，我们的目标是为此类工具提供一种方法来捕获分析后的“有趣子集”，以便与其他工具共享。
In short: We are not interested in an UNCOL.
简而言之：我们对UNCOL不感兴趣。[这应该是个段子，但我没get到]
我们的目标是提供一种用于在工具之间共享数据的语言，虽然我们发现这对于一大类有趣的问题很有效，但总会有一些情况是高度依赖于特定语言或数据模型的。
对于这种情况，使用针对该目的进行调整的表示是比较恰当的。
What Kythe Provides
Kythe项目的核心围绕三个主题，这些主题体现在我们的开源工具中，并由Google的KYTHE团队以及任何感兴趣的贡献者提供支持：
- Language-agnostic graph storage format
与语言无关的图形存储格式：Kythe定义了一种简单、灵活且可移植的图形表示，它易于从插装的编译器中发出，并供客户端使用。 - Graph schema
图形模式：Kythe为各种语言（包括C++、Java和Go）中的各种有趣的语义交叉引用数据提供了一个简单的、可扩展的图形模式。
我们还提供了一些简单的开源工具，可以轻松地将新元素添加到模式中，并测试生成这些元素的分析器是否符合其约定。 - Analyzers, tools and examples
分析器、工具和示例：Kythe项目提供了用于生成和操作Kythe数据的开源工具，包括用于C++、Java和 Go的索引器（一个自带服务器，可以使用Kythe数据来回答交叉引用查询），以及一些UI示例代码，这些代码显示了如何将这些部分粘合在一起。
What Kythe Requires
从本质上讲，参与Kythe生态系统所需要的只是一个工具，这个工具用来使用 或 发出Kythe格式的数据，并在适当的情况下遵循Kythe模式。您需要：
To plug in a language
插入一种语言一个编译器，它可以被插装以产生一个索引器，该索引器发出关于该语言的源代码的数据。
To plug in a build system
插入一个构建系统。一个可以从构建过程中“提取”编译信息的工具，允许特定于语言的分析器在代码及其依赖项上运行。
To plug in a UI tool
插入一个UI工具。任何可以使用Kythe’s graph的工具都可以使用Kythe数据来回答有关代码的问题。唯一需要融入该工具的特定知识是命名方案。
To build a service or other analysis on Kythe data
在Kythe数据上构建服务或其他分析。Kythe数据格式简单、扁平且易于移植。工具或服务可以将Kythe’s graph数据快速转换为表格或其他结构化格式，用于快速服务、图形探索、可视化等。