（CumulativetyNO.234）
程序员搜索习惯的研究及对搜索工具开发的启示
沈 玲 黄 熹 李艳阳（江苏省扬州职业大学信息工程学院，江苏 扬州 225000）源代码搜索对在软件系统上执行故障修复任务的程序员来说是一个很重要的活动。为了改进在源代码摘要：
中发现有用信息的工具支持，文章通过一个研究来分析程序员如何决定搜索什么和怎么决定哪些搜索结果是和任务相关的，实验中要求程序员对一个他们起先不熟悉的系统完成故障修复任务。文章提出了5个观测发现和一些程序员面临的困难，同时还讨论了这些观测发现对未来源代码搜索工具设计的启示：支持略读；对结果进行排名和分组；支持对结果进行再搜索。源代码搜索；程序员；搜索习惯；搜索工具关键词：
F276 文献标识码：A 文章编号：1009-2374（2012）27-0027-04中图分类号：
1 研究方法
关于对程序的理解，现在有各种模型，比如自上而下模型、自下而上模型、综合模型等。这些模型着重于描述程序员对程序的心理表征和认知过程以及形成这个心理表征的信息结构。这些模型和理论已用于现有搜索工具的设计。我们的研究采取了一种不同的策略来影响搜索工具的设计，因而我们的结果是对程序理解领域工作的一个很好的补充。特别是我们的研究着重于填补程序员搜索活动的细节，包括他们面临的困难。我们希望这些细节能够在程序理解理论和编程搜索工具的研究和设计之间架起一个桥梁。本研究的目的并不在于提出新的搜索技术，而是通过我们的研究给将来搜索工具的开发提供灵感。
本研究是在一个实验室的环境下进行的，共有10个程序员参与（P1到P10）。参与者以前都有Java编程经验并且熟悉Java开发环境（Eclipse）。他们事先都不熟悉这个系统。参与者能不能完成任务并不重要，我们的兴趣是把他们放在一个特定的环境下，然后让他们自然地在这个软件系统中进行各种搜索。我们随机分派两个任务中的一个给每一个参与者。为了保证任务的真实
性，这两个任务都是从系统真实的故障追踪库中选取出来的。
参与者被限制在仅能使用系统提供的功能（例如使用调试器、运行程序、使用搜索工具等）。为了能够判断出他们搜索行为的有效性，我们研究了这些任务的专家解决方案，并且确定了一些源代码是和这些任务高度相关的。为了确保数据采集的可靠性，一个参与者和一个研究助理作为一对搭档一起工作。参与者给出操作指令，研究助理负责操作键盘。我们之所以这样做，是希望通过这样洞察出为什么会有不同的搜索行为。
每个参与者都给了一页纸的说明，上面描述了系统支持的8种搜索方法以确保他们知道能够进行的选择，遗憾的是参与者只使用了其中的6种方法（见图2）。
开式：支持基于部分名字或模式的类或接口 搜索。
文件：支持搜索工作区中所有文件中的文本。文件中寻找：支持在特定的文件中搜索一段 文本。
Java：搜寻Java元素（包、类型、方法和域）的声明、引用、事件。
27
引用：在特定的代码元素或匹配关键词的元素的所有引用中搜寻。
实现：在实现一个特定的接口或匹配关键词的接口的所有的类中执行搜索。
声明：在特定的代码元素或匹配关键词的元素的所有声明中搜索。
文件中的事件：在当前文件中特定的代码元素的所有事件中执行搜索。
参与者每一次使用其中的一种搜索方法，我们称之为一个搜索事件。我们的数据包括了96个完整的搜索事件。在我们的分析中，事件是作为分析的基本单元。我们的发现是基于定量数据（例如在每一个搜索事件中花费的时间）和定性数据（例如参与者对他们正在寻找的信息做的评价）的。
2 研究发现
图1所示的数据显示了参与者搜索的有效性以及他们对搜索结果处理的有效性。理想的搜索应该包含高度相关的结果和一些其他的结果，例如参与者P2进行的第四次搜索。
观察结果1：当参与者接到一个故障修复任务时，他们总是根据以前的经验形成一个假定。这个最初的假定往往是正确的并能指导他们大部分的工作。
作为刚介入到这个系统中的参与者，在任务开始的时候总是对系统源代码的结构做某种猜测。他们也需要对故障的原因做一些猜测。在对源代码做了一些最初的探究以后，往往会形成一个假设。这个结果说明假设是对程序理解和认知的结果。这两个任务中，高度相关的元素都在用户界面包中。大部分的参与者都正确地猜出了这个地方。特别是6个参与者明确指明了问题与用户界面有关系。其余4人中，有2人在用户界面包中进行了至少一次搜索。 另外一人特地在搜索结果中展开了用户界面包。
观察结果2：从假设开始，参与者基于经验和对命名惯例的预期来形成搜索队列。有时也会尝试基于同义词的多重搜索或者使用不同的方法来表达相似的想法。
参与者习惯于根据对代码中命名惯例的预期来进行搜索，当然同样的概念可以有不同的表示方法，因而参与者会尝试不同的搜索方法，也就是说28
他们使用不同的方法来表达相似的想法。
尽管参与者对可能存在的问题所做的假设是正确的，但这个过程并不总是很直接的。这个系统的搜索工具需要使用者明确指明一个具体的术语。如果提供的术语不是很准确的话，是不会返还相关的结果的。
在每一个搜索事件中，参与者在开始一个新的搜索前一般只花费很少的时间。在一个搜索事件中，花费时间最长的是5分钟，最短的是5秒钟。平均是69秒，中位值是39秒。在有些案例中，返回的大量结果似乎阻止了参与者花费大量时间来浏览整个结果。
图例
P1任务1 每个柱形条代表一个搜索事件。柱形条的高
度描述了搜索结果的数目。同时在图中也列
出了搜索类型，返回结果的数目和在源代码
编辑器中打开的次数。
P2任务2
颜色：
一个或者一个以上的高度相关的条目在
源代码编辑器中被打开过。
P3 任务2 一个或一个以上高度相关的条目出现在
返回结果中（但没有一个在源代码编辑器中被打开过）。
没有一个高度相关的条目出现在结果
中。
P4任务1
搜索类型： F 文档 J Java
P5任务1 I 文档中寻找 R 引用 O 开式 D 声明 P6任务2
P7任务2
P8任务1
P9任务1
P10任务2
图1 搜索事件
1 搜索事件
观察结果观察结果3：参与者通常对搜索什么（或在搜
3：参与者通常对搜索什么（或在搜索结果中寻找什么）总是只有模糊的概念。特
索结果中寻找什么）总是只有模糊的概念，特别是在一个任务的起始阶段。通常他们的搜索都非常笼
统，因而返回很多结果。
图2显示了使用次数排名前四位的搜索类型返回结果数目的分布图。这个图同时也显示了每种搜索返回结果的平均值。系统的文档搜索到目前为止是参与者最喜欢用的。大约一半的搜索事件都用此
法。文档搜索是最包含型的搜索（相对于Java搜索），并且对限制搜索范围只有很少的选项。
参与者所做的搜索大部分都是范围很广并且使用很常见的术语。即使是在我们研究的后期，参与者也还是比较难以清晰明白地指明能够得到高度相关结果的搜索。参与者一般都是对什么地方有问题做出假定，但是把这个转变成精确的搜索并不是能够那么直接。因为他们寻找的概念通常都是含糊的。参与者也显示出对搜索结果与任务的相关性缺乏信心，因而他们并不总是仔细探究这些结果。
96次搜索事件中有46次使用文档搜索。仅有36次返回非空的结果如上图所示。平均每次返回570个结果。
96次搜索事件中有16次使用Java搜索。仅有9次返回非空的结果如上图所示。平均每次返回92个结果。
96次搜索事件中有16次使用在特定文件中进行文档搜索。仅有10次返回非空的结果如上图所示。平均每次返回2个结果。
96次搜索事件中有13次使用引用搜索。仅有9次返回非空的结果如上图所示。平均每次返回3个结果。图2 使用次数排名前四位的搜索类型返回结果
数目分布图
观察结果4：参与者总是略读结果以寻找相关的证据（基于他们的假定），而不是系统地研究搜索结果。有时仅仅集中精力于与他们的假定一致的某个包。
从文档搜索、Java搜索、引用搜索、声明搜索返回的结果是以树形图呈现出来的。以包、类然后匹配元素来组织排列。搜索结果的绝大多数（96个中的76个）是以树形图呈现出来的。文档搜索的结果是以一行源代码（在上下文中显示了匹配的搜索
术语）的形式呈现出来的。像前面所描述的，大多数的搜索都是范围很广的，且返回大量的结果。而每一次搜索花费的时间却很短（平均68秒）。造成这样的原因是，参与者倾向于略读结果，而不是系统地探究每一个返回的条目。通常他们一开始都是粗略地考虑一下包和类的名字。
参与者根据对需要修复故障的假定来指导对包的名字的略读。他们往往会看一个包的名字是否引起他们的兴趣。集中精力于搜索结果中的各种用户界面包对参与者来说是很常见的。因为他们都假定故障是在应用的用户界面层。一旦参与者选中了一个包，他们往往倾向于再一次略过一些文件和类而去寻找一些他们感兴趣的东西。换言之，寻找与他
们手中的任务似乎相关的名字。一些参与者扩展开选中的包，这样他们就能看到上下文。这些上下文可以给参与者关于他们正在寻找的东西一些很好的想法。
在大部分的事例中，参与者很快做出决定“没有任何相关的东西”，因而尝试一个新的搜索。有趣的是，参与者在肯花时间进一步探究结果之前，他们总是需要很明确的相关的迹象。当进行一次搜
索时，需要提供特定的术语。但当略读搜索结果时最好是寻找任何一个可能有意义的东西。
观察结果5：参与者在源代码编辑器中只打开过很少的结果，并且很少再返回到原来的搜索结果中（也就是说并不是一个交互的过程）。大部分情况下，打开的元素都被略过了。
在我们的研究过程中，57次搜索返回了非空的结果。面对非空的结果，参与者需要决定在源代码编辑器中打开哪个元素。没有一个参与者打开过超过4个结果。最常见的举动（57次中的33次）是仅打开其中的一个结果。有趣的是，第二常见的举动是一个都不打开。在某些情况下，没有结果被打开意味着参与者只是略读了一下结果，没有注意到任何看起来特别相关的东西。在另外一些情形中，大量的结果阻止了广泛的调查研究。
当返回的结果量太大时，参与者倾向于只打开很少的结果，并且认为将时间花在进行另一次搜索是更明智的行为。因而在搜索结果和源代码编辑器
29
之间的交互动作来发现相关元素的行为就很少见。当选择了一个元素做进一步探究时，参与者倾向于快速略读源代码来决定这个元素是否相关。这种略读是在他们对需要解决问题的假定的指导下进行的。
3 对搜索软件设计的启示
参与者的行为可描述为搜索和略读。如果搜索工具对这些行为的支持能够改进的话，参与者在执行任务时面临的困难就能减轻。以下是一些例子。
3.1 支持略读
参与者的搜索一般都是范围很广，产生很多不相关的结果。因而他们需要继续通过略读来寻找相关的东西。好处是略读（不像搜索）不需要清晰明白地指定一个精确的术语。不好的地方是结果包含了很少程序员能够对相关性做出判断的信息。对于返回的结果，参与者能利用的是两种信息：结构化的信息（主要是包的结构）和名字。基于我们的观察，如果能在返回结果中包含上下文的信息将是非常有价值的。当然程序员在源代码编辑器中打开一个元素就能得到更多的信息。但是我们发现，当他们这样做时，他们并不倾向于返回搜索结果来探究其他的结果。如果能在搜索结果窗中提供另外的上下文的信息，这将能让程序员更快地做出是否相关的判断。
3.2 对结果进行排名和分组
参与者仅仅对一小部分的结果进行探究。并且在选择哪个元素来探究之前并不充分考虑所有的结果。基于我们的观察，我们认为对结果进行排序（基于某种信心指数）会吸引更多的注意。对于大量的返回结果，程序员容易放弃。但如果这些结果能以某种有意义的方式进行排名，程序员就很有可能能够充分利用这些结果。如何对结果进行排序是个有争议的问题，我们相信一个成功的排序需要考虑到上下文。在我们的研究中，我们发现很多参与者以包为单位来对结果进行分割。这样他们就能集中精力于比较小的子集来决定相关性。
3.3 支持对结果进行再搜索
平均每个搜索事件花费的时间是68秒，在这68秒中，只有很少的结果被探究。参与者喜欢尝试不
30
同的搜索，而不是仔细地探究这些结果，虽然有时他们也会重复以前的搜索。可能的改进是对搜索结果窗交互性支持的增强，这样能让程序员更好地利用这些结果，并且通过观察这些结果窗作为下一步探究的基础。比较可行的增强方式是，跟踪哪些已被探究过，而哪些没有；支持基于程序员判断的相关性来移去或亮显元素；支持在结果中再搜索。
4 结语
为了改进在源代码中发现有用信息的工具支持，我们进行了一个研究来探究程序员怎么决定搜索什么和什么结果对他们的任务是相关的。我们观察了10个程序员在对一个软件系统执行故障修复任务时的表现。我们搜集了96个搜索事件中的定量数据和定性数据。本文提出了对这些数据的分析结果（可概括为5个关键的观察结果），并讨论了这些结果对搜索工具设计的一些启示。
参考文献
[1] Alwis B and Murphy G．Answering conceptual queries
with ferret．In Proceedings of the international conference on Software engineering，2008：21-30.
[2] LaToza T，Garlan D，Herbsleb J，etc．Program compre-hension as fact finding．In Proceedings of Foundations of Software Engineering，2007：361-370．
[3] Poshyvanyk D，Petrenko M，Marcus A，etc．Source code
exploration with Google．In Proceedings of the IEEE In-ternational Conference on Software Maintenance，2006：334-338．
[4] Storey M，Wong K．How do program understanding tools
affect how programmers understand programs．Science of Computer Programming，2000，36：183-207．
[5] Rothermel，G．Helping End-User Programmers \"Engi-neer\" Software：an Opportunity for Empirical Researchers．Empirical Software Engineering and Measurement，2007：9-10．
作者简介：沈玲（1961-），女，江苏无锡人，江苏省扬州职业大学信息工程学院副教授，研究方向：软件与理论和应用 技术。
（责任编辑：周加转）
因篇幅问题不能全部显示，请点此查看更多更全内容