![]()
在今年 FSE 2024 软件工程大会上，阿里云通义灵码团队和重庆大学合作的论文《An Empirical Study of Code Search in Intelligent Coding Assistant: Perceptions, Expectations, and Directions》被 FSE Industry 2024 (CCF A) 录用。
![]()
本篇论文主要探讨了在智能编码助手中的代码搜索问题。通过对阿里云开发的智能编码插件进行实证调查，在用户授权下，收集了来自全球用户的超过 14 万次代码搜索事件，并通过问卷和面对面访谈等方式深入了解了开发者对代码搜索的期望和需求。结果表明，有效的代码搜索工具应该能够理解本地编程环境下的搜索意图，并提供有用的搜索结果。基于这些发现，论文提出了未来代码搜索研究的方向和建议。该研究采用了两阶段的研究方法：第一阶段为定量分析，收集了通义灵码用户授权的历史数据，并进行了调查设计；第二阶段为定性分析，包括问卷调查和访谈。在第一阶段中，通过收集通义灵码用户的搜索历史记录，分析了用户使用代码搜索工具的过程、查询方式以及结果反馈等信息，从而了解用户对代码搜索工具的偏好和需求。在第二阶段中，通过问卷调查和访谈的方式获取用户的实际使用情况和期望，进一步深入探究用户的需求和期望，以便更好地改进和完善代码搜索工具的功能和服务。
![]()
调研统计涉及了 2022 年 4 月-2023 年 4 月的 24543 名用户（机器 ID 匿名上报，可能有重复）和 146893 次代码搜索事件数据。得到了一些结论：1. 与 API 搜索相比，语义搜索在 IDE 中更常被使用。大多数开发人员根据需要执行代码搜索，因此有效的工具应该始终提供有用的结果。
2. 用户查询通常是短小精悍的，根据常见用户输入推荐相关查询对于确定所需的查询很有用。开发人员有时会提交冗长的查询，通过复制运行时日志进行调试。对于语义搜索查询，包含本地语言（例如，中文）对非英语开发人员有利。
3. 开发者通常只查看代码搜索结果中排名前几（前三名）的结果。这种行为强调了对高度相关性代码搜索工具的需求。此外通过发放调研问卷，以了解用户对代码搜索的看法和未来期望。该问卷是在对定量分析的理解和最近对代码搜索研究的系统综述的基础上起草的。它经过了阿里两位高级开发人员参与的小规模研究的改进。此外，我们还与七位受访者进行了面对面访谈，深入了解他们的调查回答，并收集了额外见解。一些主要发现包括：1. 有经验的开发人员可能不会经常进行代码搜索；但是，当他们这样做时，他们会期望工具非常有效。尽管如此，对于语义搜索用户来说，编写精确的查询仍然是一个挑战。2. 在实践中，开发人员会出于各种目的（例如程序理解）来搜索代码。他们希望未来的工具能够集成来自不同来源（例如 API 文档）的多种编程语言的代码库（例如 Go 和 JavaScript）。这些工具应该支持对代码的不同粒度的搜索（例如片段和类），并为搜索结果提供额外的质量改进（例如错误检测和编程风格检查）。3. 开发者希望代码搜索工具具有类似于 ChatGPT 的增强查询理解能力。他们期望搜索结果简明扼要、代表性强、易于理解，并且能够适应编程上下文，无需或只需很少修改。总结来讲：
- 我们对最近一个代码助手进行了全面的定量分析，以分析开发人员的代码搜索活动。随后，我们进行了调查和访谈，以获得有价值的见解。
- 我们为研究人员提供了代码搜索要求、评估和改进的未来方向。此外，我们展示了各种用户期望，以帮助从业者开发更好的工具。
数据分析主要研究下列三个问题：
- RQ1：哪种代码搜索任务被频繁使用？该问题旨在确定开发人员对代码搜索类型的偏好：语义搜索还是 API 搜索。
- RQ2：查询的特点是什么？本题考察用户查询，重点关注词数和语言，并分析两种代码搜索类型的差异。
- RQ3：开发者通常会查看多少个搜索结果？这个问题的目标是量化平均数量。
问卷访谈主要研究下列五个问题：
RQ4：开发人员对实际中的代码搜索有何看法？评估用户对代码搜索的实际性能的看法（Q3-Q5）。
RQ5：开发人员使用代码搜索的目的是什么？理解开发人员使用代码搜索工具背后的实际原因（Q6）。
RQ6：开发人员期望什么样的代码搜索输入？调查代码搜索输入的首选格式（问题7）。
RQ7：开发人员对代码库有哪些期望的扩展？提供有关编程语言（Q8）和数据源（Q9）方面的代码库潜在扩展的信息。
RQ8：开发者期望得到什么搜索结果？理解所需的格式（Q10）和增强功能（Q11）。
RQ9：代码搜索与 ChatGPT。以对调查中使用的代码搜索工具与广泛使用的 ChatGPT（Q12）之间的区别为基础，为未来的研究提供基础。
表 2 显示：展示了来自 24,543 名同意记录其代码搜索行为的用户的见解。在这些用户中，有 20,861（85%）人进行了语义搜索，而 13,413（54.7%）人使用 API 搜索来查找代码示例。值得注意的是，9,731（39.6%）名用户参与了这两种代码搜索类型。这些结果表明，许多用户希望以混合的方式使用两种代码搜索方式，并且更喜欢语义搜索而不是 API 搜索。这些用户共产生了 146,893 次代码搜索事件，其中 104,614（71.2%）次事件归因于语义搜索，42,279（18.8%）次事件归因于 API 搜索。平均而言，每天会有 402.45 次代码搜索请求，其中 286.61 和 115.83 次分别用于语义和 API 搜索。然而，对于每个用户来说，每天只有 0.02 次代码搜索事件。这表明虽然语义搜索的使用频率更高，但用户只是偶尔会使用代码搜索工具。当该工具不能满足他们的需求时，他们可能会转向替代方法，如网络搜索引擎。因此，开发人员会在实践中始终解决他们的问题时认为代码搜索工具是有价值的。![]()
表 3 显示：语义搜索查询的平均词数超过了 API 搜索（52.96 比 37.91）。根据双样本 Kolmogorov-Smirnov 检验，两项任务的词频分布存在显着差异（p 值 <0.05）。然而，语义搜索和 API 搜索的中位数计数显示了相反的大小关系（16 与 36）。这些结果表明，在大多数情况下，语义搜索查询往往较短，而 API 搜索查询较长。如图 1 所示，由于开发人员经常选择工具推荐的完全限定名称的候选 API，因此 API 搜索查询往往更长。这种推荐有助于用户定位目标 API。此外，人们普遍认为语义搜索查询是简洁的，通常由动词短语组成。我们观察到开发人员可能会通过从工具中选择推荐的候选查询或复制运行时日志来输入冗长的查询以查找调试代码示例。因此，开发人员不仅期望语义搜索充当编码助手，如现有研究所示，还希望它充当调试助手。![]()
表 4 显示：74.7% 的查询以英语书写，而 13.0% 的查询仅包含本族语（即中文）单词，12.3% 的查询涉及两种语言的组合。常见的做法是，API 搜索用户直接在英文中输入 API 名称。相比之下，语义搜索包括了 19,124 个中文查询和 17,978 个包含多种语言的查询。这表明当用户难以用英语清楚地表达自己的需求时，本地语言可能会起到辅助作用。![]()
表 5 显示了代码搜索成功率低（0.21）。语义和 API 搜索的结果没有统计学意义（p 值 <0.05），根据双样本 Kolmogorov-Smirnov 测试，在显著性水平为 5% 的情况下。这主要是因为开发人员通常只查看前几个搜索结果（#Viewed <14），并且他们发现有趣的搜索结果的数量往往少于两个（#Interested <2）。这些结果证实了现有代码搜索研究中的假设。在我们的研究中，代码搜索工具的性能较低，其 MRR 为 0.16。语义和 API 搜索在两样本 Kolmogorov-Smirnov 测试中的 p 值无统计学差异。然而，在用户认为有趣的结果方面，MRR 显著较高，在前三个排名中达到 0.77，并且平均 FRank 为 2.29。这些结果表明，如果出现在前三名，开发人员倾向于点击他们觉得有趣的结果，以探索细节或选择复制粘贴。然而，在许多情况下，搜索结果不能直接应用于满足用户的实现要求。此外，开发人员可能会基于有用的搜索结果编写代码，或者表达对某些代码的兴趣而不采取进一步的行动。因此，衡量代码搜索的实际性能仍然具有挑战性。![]()
图 5 显示，9（16.98%）参与者很少执行代码搜索（0 到 2 次），而 28（52.83%）参与者表示中等频率地执行代码搜索（3 到 5 次）。其余 3 名参与者以高频率（11 至 15 次）或更高频率（> 15 次）执行代码搜索。根据受访者的反馈，他们“只在需要时才使用代码搜索工具”，并且他们“非常了解其编码环境”。这种趋势可能是受访者经验丰富的结果。因此，每个用户每天平均执行代码搜索的次数保持较低，如第节中讨论的那样。![]()
有 48 位（占 90.57%）受访者经常使用语义搜索，而约 64.15% 的受访者使用了 API 搜索。这些结果表明用户对软件编程中这两种代码搜索方式有着显著的偏好。图 6 列出了受访者报告的有用性级别。这表明，27 名受访者（占 50.94%）认为语义搜索具有中等程度的实用性，而 12 名受访者（占 22.64%）则认为其实用性较低。此外，有 10 名受访者表示，语义搜索非常有用。其余 4 名受访者（占 7.55%）声称其效用极低。在 API 搜索方面，大多数受访者（占 45.28%）也认为其效用一般，有 13 名受访者表示其效用很高。然而，14 名受访者（占 26.42%）认为 API 搜索的效用很低或非常低。这些结果表明，尽管后者被更多的用户使用，如之前所述，但人们普遍认为 API 搜索比语义搜索更有用。几位受访者指出，“与 API 搜索相比，语义搜索很难准确描述查询”。图 7 提供了代码搜索的一些目的。受访者中，有 47 位（88.68%）表示首选目的是实现需求。许多受访者表示，“虽然一些搜索结果是有用的”，但他们“通常自己编写代码”。这种反馈表明代码搜索与开发者编码过程之间存在差距，这可能会导致前文报告的中等效用水平，并解释为什么许多用户不会对搜索结果采取进一步操作，此外，45 位受访者（84.91%）预期能够通过该工具理解代码示例，例如学习如何使用特定的 API。然而，一位受访者指出，“有时代码很长，很难知道哪部分可能有用，因此可以跳过这个结果”。因此，返回简洁且有代表性的代码示例对于代码搜索工具的有效性至关重要。![]()
随后，33 名受访者（占 62.26%）表示更喜欢使用代码搜索工具来查找编程错误的解决方案。根据受访者的反馈，在遇到编程错误时，他们通常会“复制错误信息或相关源代码到搜索引擎中，并尝试找到一些解决方案”。正如前文分析的那样，这种做法可能会导致查询语句过长。然而，现有的代码搜索工具并不总是适用于此类查询。此外，18 名受访者（占 33.96%）希望代码搜索结果能帮助他们修复漏洞。最后，13 名和 11 名受访者预计理想的代码搜索工具可以帮助他们优化（占 24.53%）或重构（占 20.75%）返回的代码。尽管如此，一些经验丰富的受访者指出，“我想自己来做优化或重构”，这是因为“它们是我的强项；我会决定这些任务是否需要紧急完成。”
图 8 列出了通义灵码中没有包含的五种代码搜索方法。它揭示了 33 名受访者（62.26%）对代码克隆搜索的兴趣，即输入代码片段以检索代码库中的相似代码。此外，22 名受访者（37.74%）希望根据给定的测试用例搜索目标源代码。另外，13 名受访者（24.53%）预计会使用用户界面草图来搜索代码。其余 18 名受访者希望有一个理想的代码搜索工具，该工具可以根据输入输出示例（15.09%）或语音（5.66%）工作。受访者表示，代码克隆搜索是有价值的，因为它可以让他们“找到一些相同的修改的重复代码段”。然而，许多受访者对其他代码搜索方法的有效性提出了疑问，因为他们“想不出任何例子来使用它们”。![]()
图 9 显示，许多受访者支持在代码搜索中扩展 Java，以包含另外三种编程语言：Go（77.4%）、JS/TS（62.62%）和 Python（75.5%）。C/C++、Ruby 和 C# 各有 13 票。PHP 和 Rust 各获得另外 13 次选择。这些结果强调了开发者实际使用编程语言的多样性。所有受访者都强调了这种扩展的必要性，因为“他们需要使用它”。此外，一位受访者强调了扩展 Rust 的实用性，因为“这门编程语言对他们来说是新的”。![]()
表 10 显示，超过 33 名受访者表示有兴趣从其他开源社区（86.79%）、问答社区（66.04%）和官方 API 文档（62.62%）中添加其他搜索源。这些来源与受访者所描述的开发人员常见的搜索实践相一致。此外，20 名受访者（37.74%）选择了网络搜索，受访者指出“网络搜索涉及许多其他来源”。14 名受访者（26.42%）发现本地存储库中的代码搜索有用。一名受访者表示，“如果我有权限，我想知道在企业级本地存储库中如何实现要求。”此外，还有 10 人、3 人和 2 人（18.87%）选择漏洞数据库。![]()
图 11 表明，大多数受访者（>88%）表示对搜索代码功能或片段感兴趣。受访者指出这两种类型很有用，因为它们“需求通常很小很具体”，并且他们“希望分解这些要求”。此外，27 名受访者（50.94%）发现搜索类很有用，而另外 14 名受访者更喜欢搜索存储库（22.64%）或文件（3.77%）。这些结果强调了开发人员对搜索更高粒度的代码目标的期望。![]()
图 12 展示了对代码搜索期望的七种质量改进。根据降序排列，47 位受访者（88.68%）表示需要一种工具来检查在开发人员编程环境中返回的代码中的错误。此外，39名受访者（73.58%）要求返回的代码符合他们的预期编程风格。另外，24 名受访者（37.74%）希望在检索到的源代码中搜索相关测试用例。15 名受访者（28.30%）担心代码中的敏感信息，并希望删除它们，例如秘密密钥和电子邮件地址。另外，有 13 位受访者（占 24.53%）要求未来的工具能够显示搜索代码的测试覆盖率，同样数量的受访者（占 24.53%）希望了解相关的测试失败信息。受访者表示，这种排名很自然。他们强调：1）发现错误很重要，因为“代码搜索可以帮助编写代码，但代码可能无法在集成开发环境中运行”，并且他们更喜欢“不调试搜索到的代码以节省精力”；2）“代码需要遵循企业的编程风格”；3）“其他功能看起来很有用，但不是首要任务”。表 6 显示了受访者对灵码代码搜索功能与知名 AI 语言模型 ChatGPT 之间优缺点的正面和负面评论。总的来说，代码搜索的主要优势在于快速响应时间和检索人类编写的代码，而 ChatGPT 则不具备这些特点。然而，代码搜索在处理复杂查询时面临挑战。因此，开发人员通常需要根据搜索结果来细化他们的查询，这可能会很繁琐。此外，由于搜索列表中存在许多重复的结果，评估预期结果的相关性也很费力。这些观察结果与受访者的反馈一致。此外，一位受访者提到，“当他们知道正确的关键字并有信心找到预期的代码时，他们会使用代码搜索工具”。![]()
相反，ChatGPT 在理解查询方面表现出色，生成的代码通常在两个关键方面令人满意：1）它能够生成逻辑清晰、组织良好的代码，通常只需要很少的修改就能使用；
然而，ChatGPT 的性能受到两个因素的影响。首先，它的知识边界限制了它始终生成准确答案的能力，因为一些受访者指出，ChatGPT 并不能总是提供正确的回答。受访者认为原因可能是“训练数据范围有限”。其次，ChatGPT 的性能取决于提供的提示作为输入。生成的代码可能对提示描述敏感或包含意外的 API。总的来说，受访者更喜欢 ChatGPT 而不是代码搜索，承认其优势。然而，他们也评论说：1）“ChatGPT 无法处理内部企业数据”，因为公司可能会使用自定义框架或 API 编写代码；
2）“ChatGPT 不负责每一行代码”，因此开发人员仍然需要仔细审查代码。
代码搜索对于提高开发人员生产力来说是一项重要的任务。本文报告了我们在阿里云开发的代码搜索工具灵码上的经验研究结果。我们首先对用户允许记录的代码搜索活动进行了量化分析，以了解用户的偏好。然后，我们为阿里巴巴的工具用户设计了问卷调查，旨在了解他们的看法和期望。随后，我们采访了七位用户，澄清他们对调查的回答。根据这些结果，我们为研究人员和从业者提供了未来的研究方向。在我们的未来工作中，我们计划包括更多不同规模的公司来研究我们发现的一般性。我们还计划按照建议的未来方向改进现有的代码搜索工具。
本论文成稿于 2023 年，当时正值大模型初露锋芒，大模型赋能软件研发正在尝试中。通义灵码（前身：阿里云智能编码插件）的产品形态也正在从【下拉式行级补全+代码片段与文档搜索】进化到【大模型块级补全+大模型流式问答】。
随着模型能力的提升，代码搜索没有消逝，而是和 AIGC 问答结合起来，作为训练素材和 RAG 能力加强到生成模型；随着模型能力的提升，用户寻找相关代码，学习示例用法，咨询前人经验，解决报错问题的诉求也没有改变；随着模型能力的提升，软件工程依赖经验和创新的本质也没有变。