从一年前推出我们对新的和改进的代码搜索体验的技术预览，到我们去年 11 月在 GitHub Universe 发布的公开测试版，围绕我们如何，对一些核心 GitHub 产品体验进行了一系列创新和显着变化，作为开发人员，查找、阅读和导航代码。
我们听到的关于新代码搜索体验的一个问题是，“它是如何工作的？”作为对我在 GitHub Universe 上的演讲的补充，这篇文章给出了该问题的高级答案，并提供了一个了解系统架构和产品技术基础的小窗口。
那么，它是如何工作的呢？简短的回答是，我们在 Rust 中从头开始构建了自己的搜索引擎，专门用于代码搜索领域。我们称这个搜索引擎为黑鸟，但在解释它的工作原理之前，我认为它有助于稍微了解我们的动机。乍一看，从头开始构建搜索引擎似乎是一个有问题的决定。为什么要这么做？不是已经有很多现有的开源解决方案吗？为什么要建立新的东西？
公平地说，在 GitHub 的几乎整个历史中，我们已经并且一直在尝试使用现有的解决方案来解决这个问题。您可以在 Pavel Avgustinov 的帖子GitHub 代码搜索简史中阅读更多关于我们旅程的信息，但有一点很突出：我们没有太多运气使用通用文本搜索产品来支持代码搜索。用户体验差，索引速度慢，托管成本高。有一些更新的、特定于代码的开源项目，但它们肯定无法达到 GitHub 的规模。因此，了解所有这些后，我们有动力通过三件事来创建我们自己的解决方案：
我们有一个全新的用户体验愿景，即能够提出代码问题并通过迭代搜索、浏览、导航和阅读代码获得答案。
我们了解代码搜索与一般文本搜索有着独特的区别。代码已经被设计成可以被机器理解，我们应该能够利用这种结构和相关性。搜索代码也有独特的要求：我们要搜索标点符号（例如，句号或左括号）；我们不想阻止；我们不希望从查询中删除停用词；并且，我们要使用正则表达式进行搜索。
GitHub 的规模确实是一个独特的挑战。当我们第一次部署 Elasticsearch 时，花了几个月的时间来索引 GitHub 上的所有代码（当时大约有 800 万个存储库）。今天，这个数字超过了 2 亿，而且代码不是静态的：它在不断变化，这对搜索引擎来说很难处理。对于测试版，您目前可以搜索近 4500 万个存储库，代表 115TB 的代码和 155 亿个文档。
归根结底，现成的东西都不能满足我们的需求，所以我们从头开始构建了一些东西。
