程序員搜索習慣的研究及對搜索工具開發的啟示

摘要：源代碼搜索對在軟件系統上執行故障修復任務的程序員來說是一個很重要的活動。為了改進在源代碼中發現有用信息的工具支持，文章通過一個研究來分析程序員如何決定搜索什么和怎么決定哪些搜索結果是和任務相關的，實驗中要求程序員對一個他們起先不熟悉的系統完成故障修復任務。文章提出了5個觀測發現和一些程序員面臨的困難，同時還討論了這些觀測發現對未來源代碼搜索工具設計的啟示：支持略讀；對結果進行排名和分組；支持對結果進行再搜索。

關鍵詞：源代碼搜索；程序員；搜索習慣；搜索工具

中圖分類號：F276 文獻標識碼：A 文章編號：1009-2374（2012）27-0027-04

1 研究方法

關于對程序的理解，現在有各種模型，比如自上而下模型、自下而上模型、綜合模型等。這些模型著重于描述程序員對程序的心理表征和認知過程以及形成這個心理表征的信息結構。這些模型和理論已用于現有搜索工具的設計。我們的研究采取了一種不同的策略來影響搜索工具的設計，因而我們的結果是對程序理解領域工作的一個很好的補充。特別是我們的研究著重于填補程序員搜索活動的細節，包括他們面臨的困難。我們希望這些細節能夠在程序理解理論和編程搜索工具的研究和設計之間架起一個橋梁。本研究的目的并不在于提出新的搜索技術，而是通過我們的研究給將來搜索工具的開發提供靈感。

本研究是在一個實驗室的環境下進行的，共有10個程序員參與（P1到P10）。參與者以前都有Java編程經驗并且熟悉Java開發環境（Eclipse）。他們事先都不熟悉這個系統。參與者能不能完成任務并不重要，我們的興趣是把他們放在一個特定的環境下，然后讓他們自然地在這個軟件系統中進行各種搜索。我們隨機分派兩個任務中的一個給每一個參與者。為了保證任務的真實性，這兩個任務都是從系統真實的故障追蹤庫中選取出來的。

參與者被限制在僅能使用系統提供的功能（例如使用調試器、運行程序、使用搜索工具等）。為了能夠判斷出他們搜索行為的有效性，我們研究了這些任務的專家解決方案，并且確定了一些源代碼是和這些任務高度相關的。為了確保數據采集的可靠性，一個參與者和一個研究助理作為一對搭檔一起工作。參與者給出操作指令，研究助理負責操作鍵盤。我們之所以這樣做，是希望通過這樣洞察出為什么會有不同的搜索行為。

每個參與者都給了一頁紙的說明，上面描述了系統支持的8種搜索方法以確保他們知道能夠進行的選擇，遺憾的是參與者只使用了其中的6種方法（見圖2）。

開式：支持基于部分名字或模式的類或接口搜索。

文件：支持搜索工作區中所有文件中的文本。

文件中尋找：支持在特定的文件中搜索一段文本。

Java：搜尋Java元素（包、類型、方法和域）的聲明、引用、事件。

引用：在特定的代碼元素或匹配關鍵詞的元素的所有引用中搜尋。

實現：在實現一個特定的接口或匹配關鍵詞的接口的所有的類中執行搜索。

聲明：在特定的代碼元素或匹配關鍵詞的元素的所有聲明中搜索。

文件中的事件：在當前文件中特定的代碼元素的所有事件中執行搜索。

參與者每一次使用其中的一種搜索方法，我們稱之為一個搜索事件。我們的數據包括了96個完整的搜索事件。在我們的分析中，事件是作為分析的基本單元。我們的發現是基于定量數據（例如在每一個搜索事件中花費的時間）和定性數據（例如參與者對他們正在尋找的信息做的評價）的。

2 研究發現

圖1所示的數據顯示了參與者搜索的有效性以及他們對搜索結果處理的有效性。理想的搜索應該包含高度相關的結果和一些其他的結果，例如參與者P2進行的第四次搜索。

觀察結果1：當參與者接到一個故障修復任務時，他們總是根據以前的經驗形成一個假定。這個最初的假定往往是正確的并能指導他們大部分的工作。

作為剛介入到這個系統中的參與者，在任務開始的時候總是對系統源代碼的結構做某種猜測。他們也需要對故障的原因做一些猜測。在對源代碼做了一些最初的探究以后，往往會形成一個假設。這個結果說明假設是對程序理解和認知的結果。這兩個任務中，高度相關的元素都在用戶界面包中。大部分的參與者都正確地猜出了這個地方。特別是6個參與者明確指明了問題與用戶界面有關系。其余4人中，有2人在用戶界面包中進行了至少一次搜索。

另外一人特地在搜索結果中展開了用戶界面包。

觀察結果2：從假設開始，參與者基于經驗和對命名慣例的預期來形成搜索隊列。有時也會嘗試基于同義詞的多重搜索或者使用不同的方法來表達相似的想法。

參與者習慣于根據對代碼中命名慣例的預期來進行搜索，當然同樣的概念可以有不同的表示方法，因而參與者會嘗試不同的搜索方法，也就是說他們使用不同的方法來表達相似的想法。

盡管參與者對可能存在的問題所做的假設是正確的，但這個過程并不總是很直接的。這個系統的搜索工具需要使用者明確指明一個具體的術語。如果提供的術語不是很準確的話，是不會返還相關的結果的。

在每一個搜索事件中，參與者在開始一個新的搜索前一般只花費很少的時間。在一個搜索事件中，花費時間最長的是5分鐘，最短的是5秒鐘。平均是69秒，中位值是39秒。在有些案例中，返回的大量結果似乎阻止了參與者花費大量時間來瀏覽整個結果。

觀察結果3：參與者通常對搜索什么（或在搜索結果中尋找什么）總是只有模糊的概念，特別是在一個任務的起始階段。通常他們的搜索都非?；\統，因而返回很多結果。

圖2顯示了使用次數排名前四位的搜索類型返回結果數目的分布圖。這個圖同時也顯示了每種搜索返回結果的平均值。系統的文檔搜索到目前為止是參與者最喜歡用的。大約一半的搜索事件都用此法。文檔搜索是最包含型的搜索（相對于Java搜索），并且對限制搜索范圍只有很少的選項。

參與者所做的搜索大部分都是范圍很廣并且使用很常見的術語。即使是在我們研究的后期，參與者也還是比較難以清晰明白地指明能夠得到高度相關結果的搜索。參與者一般都是對什么地方有問題做出假定，但是把這個轉變成精確的搜索并不是能夠那么直接。因為他們尋找的概念通常都是含糊的。參與者也顯示出對搜索結果與任務的相關性缺乏信心，因而他們并不總是仔細探究這些結果。

96次搜索事件中有46次使用文檔搜索。僅有36次返回非空的結果如上圖所示。平均每次返回570個結果。

96次搜索事件中有16次使用Java搜索。僅有9次返回非空的結果如上圖所示。平均每次返回92個結果。

96次搜索事件中有16次使用在特定文件中進行文檔搜索。僅有10次返回非空的結果如上圖所示。平均每次返回2個結果。

96次搜索事件中有13次使用引用搜索。僅有9次返回非空的結果如上圖所示。平均每次返回3個結果。

觀察結果4：參與者總是略讀結果以尋找相關的證據（基于他們的假定），而不是系統地研究搜索結果。有時僅僅集中精力于與他們的假定一致的某個包。

從文檔搜索、Java搜索、引用搜索、聲明搜索返回的結果是以樹形圖呈現出來的。以包、類然后匹配元素來組織排列。搜索結果的絕大多數（96個中的76個）是以樹形圖呈現出來的。文檔搜索的結果是以一行源代碼（在上下文中顯示了匹配的搜索術語）的形式呈現出來的。像前面所描述的，大多數的搜索都是范圍很廣的，且返回大量的結果。而每一次搜索花費的時間卻很短（平均68秒）。造成這樣的原因是，參與者傾向于略讀結果，而不是系統地探究每一個返回的條目。通常他們一開始都是粗略地考慮一下包和類的名字。

參與者根據對需要修復故障的假定來指導對包的名字的略讀。他們往往會看一個包的名字是否引起他們的興趣。集中精力于搜索結果中的各種用戶界面包對參與者來說是很常見的。因為他們都假定故障是在應用的用戶界面層。一旦參與者選中了一個包，他們往往傾向于再一次略過一些文件和類而去尋找一些他們感興趣的東西。換言之，尋找與他們手中的任務似乎相關的名字。一些參與者擴展開選中的包，這樣他們就能看到上下文。這些上下文可以給參與者關于他們正在尋找的東西一些很好的想法。

在大部分的事例中，參與者很快做出決定“沒有任何相關的東西”，因而嘗試一個新的搜索。有趣的是，參與者在肯花時間進一步探究結果之前，他們總是需要很明確的相關的跡象。當進行一次搜索時，需要提供特定的術語。但當略讀搜索結果時最好是尋找任何一個可能有意義的東西。

觀察結果5：參與者在源代碼編輯器中只打開過很少的結果，并且很少再返回到原來的搜索結果中（也就是說并不是一個交互的過程）。大部分情況下，打開的元素都被略過了。

在我們的研究過程中，57次搜索返回了非空的結果。面對非空的結果，參與者需要決定在源代碼編輯器中打開哪個元素。沒有一個參與者打開過超過4個結果。最常見的舉動（57次中的33次）是僅打開其中的一個結果。有趣的是，第二常見的舉動是一個都不打開。在某些情況下，沒有結果被打開意味著參與者只是略讀了一下結果，沒有注意到任何看起來特別相關的東西。在另外一些情形中，大量的結果阻止了廣泛的調查研究。

當返回的結果量太大時，參與者傾向于只打開很少的結果，并且認為將時間花在進行另一次搜索是更明智的行為。因而在搜索結果和源代碼編輯器之間的交互動作來發現相關元素的行為就很少見。當選擇了一個元素做進一步探究時，參與者傾向于快速略讀源代碼來決定這個元素是否相關。這種略讀是在他們對需要解決問題的假定的指導下進行的。

3 對搜索軟件設計的啟示

參與者的行為可描述為搜索和略讀。如果搜索工具對這些行為的支持能夠改進的話，參與者在執行任務時面臨的困難就能減輕。以下是一些例子。

3.1 支持略讀

參與者的搜索一般都是范圍很廣，產生很多不相關的結果。因而他們需要繼續通過略讀來尋找相關的東西。好處是略讀（不像搜索）不需要清晰明白地指定一個精確的術語。不好的地方是結果包含了很少程序員能夠對相關性做出判斷的信息。對于返回的結果，參與者能利用的是兩種信息：結構化的信息（主要是包的結構）和名字。基于我們的觀察，如果能在返回結果中包含上下文的信息將是非常有價值的。當然程序員在源代碼編輯器中打開一個元素就能得到更多的信息。但是我們發現，當他們這樣做時，他們并不傾向于返回搜索結果來探究其他的結果。如果能在搜索結果窗中提供另外的上下文的信息，這將能讓程序員更快地做出是否相關的判斷。

3.2 對結果進行排名和分組

參與者僅僅對一小部分的結果進行探究。并且在選擇哪個元素來探究之前并不充分考慮所有的結果?；谖覀兊挠^察，我們認為對結果進行排序（基于某種信心指數）會吸引更多的注意。對于大量的返回結果，程序員容易放棄。但如果這些結果能以某種有意義的方式進行排名，程序員就很有可能能夠充分利用這些結果。如何對結果進行排序是個有爭議的問題，我們相信一個成功的排序需要考慮到上下文。在我們的研究中，我們發現很多參與者以包為單位來對結果進行分割。這樣他們就能集中精力于比較小的子集來決定相關性。

3.3 支持對結果進行再搜索

平均每個搜索事件花費的時間是68秒，在這68秒中，只有很少的結果被探究。參與者喜歡嘗試不同的搜索，而不是仔細地探究這些結果，雖然有時他們也會重復以前的搜索。可能的改進是對搜索結果窗交互性支持的增強，這樣能讓程序員更好地利用這些結果，并且通過觀察這些結果窗作為下一步探究的基礎。比較可行的增強方式是，跟蹤哪些已被探究過，而哪些沒有；支持基于程序員判斷的相關性來移去或亮顯元素；支持在結果中再搜索。

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 comprehension 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 International 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 \"Engineer\" Software：an Opportunity for Empirical Researchers.Empirical Software Engineering and Measurement，2007：9-10.

作者簡介：沈玲（1961-），女，江蘇無錫人，江蘇省揚州職業大學信息工程學院副教授，研究方向：軟件與理論和應用

技術。

（責任編輯：周加轉）