社交化軟件開發問答中的交互過程研究

王 海 彭 鑫 于 涵 趙文耘

(復旦大學軟件學院 上海 201203) (復旦大學上海市數據科學重點實驗室 上海 201203)

社交化軟件開發問答中的交互過程研究

王 海 彭 鑫 于 涵 趙文耘

(復旦大學軟件學院 上海 201203) (復旦大學上海市數據科學重點實驗室 上海 201203)

在軟件開發在線問答網站上，解決問題的過程并非簡單的一問一答，而經常包含著一個復雜的交互過程。深刻理解軟件開發在線問答網站的問答特點及其交互過程，對于提高問題和回答質量、改進交互效率以及開發相關的自動化輔助工具都有著重要的意義。從StackOverflow中問題的目的和意圖、基本要素以及所包含的交互方式三個角度開展研究，抽樣并分析1 001個問題，總結出問題的7種類型、8個要素和10類交互方式。根據研究結果，對軟件開發在線問答網站的使用者、開發者以及輔助問答工具的研究者提出了相應的建議。

軟件開發 問答 StackOverflow 社會學習 交互

0 引 言

現代軟件開發所涉及的技術體系越來越復雜，軟件開發人員經常會碰到各種無法解決的技術問題，需要通過各種方法進行求助。隨著各種問答網站的興起，軟件開發人員也正越來越多地依賴于在線問答而非個別請教的方式進行軟件開發問題求助。除了基本的問答功能外，這些網站還提供了諸如用戶積分、點贊、正確答案標記等社交功能。

軟件開發在線問答網站上的問答過程并非簡單的一問一答，而是經常包含復雜的交互式問答過程。這是由多方面的原因引起的，例如：提問者無法準確表達自己的意思或遺漏重要的信息，需要進一步補充和澄清；提問者在已有回答基礎上繼續追問其他相關的問題；回答者需要提問者確認給出的解答或其他信息。很多問題都是在問答雙方(回答者可能不止一人)持續的交互過程中逐步得到澄清和解答的。因此，深刻理解軟件開發在線問答網站的交互過程對于提高問題和回答質量、改進交互效率以及開發相關的自動化輔助工具都有著重要的意義。

在目前的軟件開發在線問答網站中，StackOverflow(簡稱SO)是最活躍、使用最廣泛的網站之一。SO的用戶可以通過直接搜索相關問題解決自己在軟件開發技術學習或開發實踐中遇到的困難。如果無法找到相關的問題或已有的回答不令人滿意，用戶可以提出新的問題并等待其他用戶進行解答。此外，用戶也可以回答其他人提出的問題。已有的經驗研究結果表明，SO上有超過92%的問題得到了解答，而這些問題收到答案所需時間的中位數僅為11分鐘[1]。

因此，本文以SO為例，對社交化軟件開發問答中的交互過程進行了經驗研究。本文的研究圍繞以下3個方面的研究問題RQ(Research Question)展開：

RQ1：按照提問的目的進行區分，軟件開發人員經常會問到哪些不同類型的軟件開發問題？

RQ2：一個完整、清晰的軟件開發問題陳述應當包含哪些基本要素？

RQ3：問答雙方經常采取哪些交互行為和交互方式來進行問題澄清和回答？

RQ1主要針對提問者各種不同的提問目的和意圖，例如尋求實現方法或出錯解決方案等。問題的意圖不清可能導致回答者以及其他用戶無法準確理解問題的含義。而RQ2則針對不同類型的問題完整、準確地描述所需的必要成分。例如，一個標題為“連接數據庫時碰到困難了，該怎么解決”的問題意圖可能是獲取連接數據庫的樣例代碼，那么提問者應該提供諸如數據庫、開發語言之類的信息，而回答者則需要給出示例代碼。同樣標題的問題意圖也可以是連接數據庫代碼出錯需要進行排除，那么此時提問者應該提供諸如錯誤日志這樣的信息，而回答者則需要提供解決建議并持續指導提問者解決問題。RQ3針對問答雙方的整個交互過程，包括交互策略、澄清及確認信息等，目的是理解在此過程中問答雙方(回答者可能不止一人)如何相互溝通從而最終完成整個問答過程。

為了回答上述三個研究問題，本文從SO數據集中隨機挑選了1 001個軟件開發問題作為樣本進行研究并詳細分析了其中的每一個樣本。根據經驗研究結果，本文將常見的軟件開發問題進行了分類，歸納了不同類型的問題極其所需要的內容要素，還對常見的問答雙方交互方式進行了分析。在此基礎上，本文根據經驗研究結果對社交化軟件開發在線問答網站的使用者、開發者以及輔助問答工具的研究者提出了相應的建議。

1 背景介紹

StackOverflow(SO)是針對專業程序員的問答網站,建立于2008年。由于完全免費并且開放注冊，在之后的幾年內SO得以快速發展。

在SO上，問題和答案都是由用戶發出。然而和其他論壇不同的是，SO并不鼓勵討論，用戶發布內容的唯一目的就是獲得答案。因此SO的頁面都是針對解決具體技術問題而設計的。注冊用戶可以在網頁上提出或者回答問題。為了更清晰地描述問題或者給出答案，用戶還可以修改其他用戶發出的問題或者答案。

在SO上，一個問題包含標題、正文、評分、評論以及標簽5個部分。用戶可以給一個問題投贊成票或者反對票，贊成票和反對票的差值就是問題評分。問題標簽用于刻畫問題的領域或話題，一般由用戶提供，主要目的是幫助用戶更方便地找到感興趣的問題。

SO上的一個問題可以有多個答案，每個答案都包括答案正文、答案評分和答案評論3個部分。和問題類似，答案也可以被投贊成票和反對票，兩者的差值就是答案評分。默認情況下，答案將根據評分由高到低顯示。此外，提問者可以把一個答案標記成“已接受”。接受一個答案并不是必須的，但無論采用什么排序方式，只要存在已接受的答案，這個答案就會被排列在最前面。

用戶可以通過問題和答案的評論與其他人進行交流。這些評論通常被用來澄清問題或答案。每一條評論也都有一個評分以衡量其有用程度。與問題和答案不同的是，評論只可以被贊成而不能反對。

除了上面這些主要要素外，SO還有名聲和徽章系統。用戶可以在帖子被贊成時獲得名聲。高名聲可以為用戶帶來諸如使用高級工具等權限。名聲和徽章系統鼓勵了用戶積極參與，提供高質量的問題和答案，以此提升整個網站的問題質量。

截至2016年2月2日，SO已經擁有大約1 100萬個問題，1 800萬個回答，4 500萬條評論以及4萬多個標簽。此外，SO目前擁有大約510萬用戶，平均每天被訪問820萬次并有8千多個新問題被提出。

2 研究過程

2.1 概 覽

本文的研究包含三個步驟。第一步是數據準備，統計了數據集的一些基本情況。第二步是前導研究，本文的第一和第三作者在SO上隨機挑選了100個問題進行閱讀和分析。根據這100個問題，總結出了3個分析角度并設計了一個問卷用以收集數據。最后一步是深入分析，對通過隨機分層抽樣得到的1 001個問題進行細致分析。一共有10名研究生參與到最后一步中。他們被邀請閱讀這些問題并完成調查問卷已收集數據。通過分析收集到的數據，得以回答三個研究問題。

2.2 數據準備

本文使用的數據來自StackExchange官方發布的公開數據集。這類數據由StackExchange每2到3個月發布一次。本文所使用的數據集發布于2013年9月，下文將這個包含所有問題的數據集稱為全集。

在全集中，一共有來自2 332 403個用戶的5 648 975個問題和10 284 554個答案，平均每個問題1.82個答案。在全集中， 90.0%的問題擁有答案。在這些擁有答案的問題中，有“已接受”答案的問題比例是66.7%。這個比例并不是很高，這是因為接受一個答案并不是必須的。

本文還統計了問題和答案的評分數據。所有問題的平均評分是1.59，標準差是9.46。所有答案的平均評分是2.07，標準差是10.1。圖1(a)和圖1(b)展示了全集中問題和答案的評分分布。所有擁有“已接受”答案的問題的平均評分是2.07，而所有“已接受”的答案的平均評分是3.31。

除了問題和答案，本文還統計了評論相關的數據。問題評論一共有8 726 252條，平均每個問題3.04條評論；答案評論一共有13 937 529條，平均每個答案2.7條。上述所有數據如表1所示。

本文的研究需要分析SO上問答過程中的交互行為。由于交互行為無法通過自動化的手段進行分析，本文選擇人工對這些問答進行閱讀和分析。因此，作為分析對象被選取的問答不能超出研究者的知識范圍。由于本研究中所有參與者都擁有超過三年的Java開發經驗，研究對象被限制在所有被標記了Java標簽的問題中。下文將這個被選取的數據集稱為樣本集。樣本集中的各項統計量如圖1和表1所示。

圖1 問題和答案評分分布圖

2.3 前導研究

前導研究的目的是找出本文需要收集哪些數據以回答三個研究問題。首先，本文的第一和第三作者通過人工閱讀并討論的方式對SO上的問題進行了研究。在討論之后，總結出需要關注的三個方面：問題類型、問題要素以及交互行為。第三節將對這三個方面進行介紹。

表1 全集和樣本集的統計數據

問題的內容和形式是由用戶以自然語言的方式給出的，無法通過自動化的方式從中收集數據。因此在之后的深入分析中，10名研究生將被邀請輔助進行數據收集工作。然而，由于沒有參與之前的討論，他們很難準確地分析問答并從中收集數據。為了幫助他們更準確地收集數據，本文設計了一個問卷。在設計完問卷之后，一位博士生和一位研究生被邀請來幫助改進問卷。該博士生擁有豐富的研究經驗，而碩士生則擁有豐富的SO使用經驗。20個隨機抽取的SO上的問題被分配給兩人分別獨自閱讀。閱讀后他們為每個問題完成一份問卷。通過對比兩組問卷的結果并與兩位進行討論，對調查問卷進行了調整。

最終的問卷包含五個部分。第一部分是用來收集問題的基本信息，包括問題的編號和問題標題。其他一些基本信息可以從數據集中自動抽取，因此不需要被包含在問卷中。問卷的第二部分是和問題類型相關的。這部分是一個多項選擇題，問卷提供了在之前的討論中發現并總結出的問題類型供選擇。如果填寫者覺得閱讀的問題并不屬于已經提供的任何類型，他也可以選擇“其他”并填寫一個新的類型。由于一個問題有可能關注多個點，因此問題類型是多選的。問卷的第三部分是關于問題要素的。填寫者可以從問卷提供的候選項中選擇任意多個他們認為問題中包含的要素或通過選擇“其他”來提供其他要素。問卷的第四部分是關于交互行為的，問卷也提供了一些候選項。和問題類型、問題要素一樣，問卷也為交互行為提供了“其他”選項。問卷的最后部分是一個可選內容。填寫者可以在這部分填寫任何他認為值得注意的內容。

2.4 深入分析

在收集數據之前，本文采用分層采樣的方法選取了樣本。這個分層采樣遵循以下規則：

? 采樣的全集是樣本集。

? 采樣過程是一個根據問題評分的按比例分層采樣。

? 每層的抽樣都是隨機抽樣過程。

根據以上規則，本文一共抽樣選取了1 001個問題。每個評分區間的問題數量如表2所示。

表2 各個評分區間的問題數量

這1 001個問題被分成10組，其中9組100個，1組101個。這10組問題被隨機分配給10名研究生并要求他們針對每個問題填寫一份在前導研究中設計的問卷。在他們完成所有問題的分析后，第一和第三作者人工檢查了所有“其他”選項和最后一部分可選內容。對其中有異議的部分與問卷填寫者進行了討論，達成一致意見后計入統計數據。

3 研究結果

本節將以定量和定性分析的方式呈現本文的研究結果，以回答三個研究問題。

3.1 問題類型

通過分析數據，發現SO上的大部分問題都可以和圖2所示的常見困難解決流程中某一個階段聯系起來。為了解決實現某個特定功能的問題，開發者需要先分析問題的可行性分析(Feasibility Analysis)，比如是否可以在特定環境或者通過特定途徑解決這個問題。一旦確認了問題的可行性分析，開發者就會開始解決方案規劃(Solution Planning)，這包括解決方法和需要使用的工具以及其他可能遇到技術問題。然后開發者會開始實現規劃好的解決方案(Implementation)。實現完成后，如果發現了錯誤，開發者需要糾正這些錯誤(Correction)。另一方面，開發者需要對實現結果進行評估(Evaluation)。如果他覺得目前的實現還不完善的話，他還會對其進行計劃改進(Improvement)并開始新一輪的實現過程。

圖2 常見的困難解決流程

除了跟上述的六個解決困難的階段相關的問題外，還有一類問題是針對通用知識而非特定困難的。綜上，SO的大部分問題都可以被歸類到以下七種類型中去。

(1) 可行性分析

開發者會在可行性分析階段提出這類問題，其目的是詢問在特定環境下或者使用某種特定技術達到某種目標的可行性。例如，在編號為17825860的問題“How to read properties file from one project into another project?”中，開發者詢問是否可以從其他項目中讀取配置文件。

(2) 解決方案規劃

開發者在解決方案規劃時提出此類問題，其目的是了解應用某個特定技術的最佳實踐或者尋求解決手頭問題的工具。例如，在編號為9973066的問題“Best Practices: JSON for data exchange for RESTful web services using Apache CXF”中，開發者詢問在新的場景中擴展POJOs的JSON的最佳使用方法。

(3) 實現

開發者在實施解決方案中遇到困難時會詢問此類問題。例如，在編號8908313的問題“Writing correct JFrames for all Window Manager”中，開發者詢問為了適應不同大小的屏幕和不同的分辨率，應該如何設置JFrame窗口的大小。

(4) 糾錯

開發者在錯誤分析或者糾正錯誤和異常的時候會詢問此類問題。例如，在編號1305307的問題“The activator for bundle is invalid”中，開發者請求分析在開發Eclipse插件時遇到非法的bundle activator的原因極其解決方案。

(5) 評估

開發者在評估解決方案時為了得到其他人對于已經實施的方案效用的反饋而詢問此類問題。例如，在編號為1584915的問題“Java: Expected overhead of the RMI protocol”中，開發者詢問兩個RMI服務器之間850～1 100毫秒的傳輸時間是否正常。

(6) 改進

開發者為了得到對已有方案的改進建議而提出此類問題。例如，在編號為9738210的問題“Java: Thread pool with many blocked tasks”中，開發者詢問為了減少內存開銷，對于他已有的線程池的實現有什么可能的改進方案。

(7) 通用知識

開發者為了了解一些軟件開發時的通用知識而提出此類問題。例如，在編號215497的問題“In Java, what’s the difference between public, default, protected, and private?”中，開發者詢問在創建類和接口以及處理繼承關系時該如何使用這些修飾符。

在深入分析階段，樣本中的大部分問題都被歸類到上述一個或多個類型中。但是，還有30個問題被標記為“其他”。在人工查閱這些問題后，發現每一個問題都是可以被歸類到上述的7個類型中去的。例如，編號為2655239的問題“Does C# have the same issues like Java with equals and getHashCode()?”一開始被歸類為“其他”，經過討論，本文認為這是一個關于C#的通用知識的問題，因此將其重新歸類為通用知識。

圖3展示了在樣本中所有問題的類型分布，同一個問題可能由于有多個關注點而屬于多個類型。例如，開發者可以在對某個實現的表現征求反饋的同時詢問可能的提升方法。從分布中可以看出，實現類的問題是最多的，占到了樣本的42.5%；其次是糾錯類，占30.2%。其他幾類問題的占比分別是可行性分析14.9%，解決方案規劃6.4%，評估3.3%，改進5.1%以及通用知識6.6%。

圖3 問題類型分布

3.2 問題要素

問題要素是問題的基本成分，他們是提問者為了表達和澄清他的問題而提供的內容。問題要素是回答者理解問題所必要的信息。

在前導研究和深入分析中一共辨識出了8種要素。這些要素之間的關系如圖4所示。

(1) 當前方案(Current Solution)

這是對于當前面對的問題的已實現的方案。提問者可以介紹其設想、設計、算法或者在解決方案中使用的方法。

圖4 問題要素及其關系

(2) 場景(Scenario)

這是問題產生的場景。它可以是由當前方案招致的真實場景，也可以是在可行性分析或解決方案規劃時所設想的場景。

(3) 錯誤(Error)

這是在場景中報告出的錯誤或者異常。

(4) 輸出(Output)

這是在場景產生的輸出內容。

(5) 環境(Environment)

這是場景發生的環境，比如操作系統、網絡條件等。

(6) 期望(Expectation)

這是提問者所期望的效果或者條件。例如，提問者可以表達他對于解決方案的響應時間或者承載能力的期望，也可是在解決方案中使用的技術的局限。

(7) 可能方案(Possible Solution)

這是提問者提議的解決方案，目的是啟發回答者。例如，提問者可以提議一個可能方案以期其可行性或效率。

(8) 代碼(Code)

這是表明在當前方案或可能方案而給出的代碼片段。例如，提問者可以提供他當前實現中的代碼片段以幫助回答者分析他的錯誤信息。

在SO中，這些要素可以用不同的方式去描述。例如，除了文本描述、期望、當前方案、場景和可能方案還可以用具體例子去描述；而錯誤、輸出和環境則可以使用引用外部技術文檔的形式去描述。除此之外，提問者還可能在沒有顯式提供問題要素的情況下提出問題。例如，提問者可以在沒提及相關場景的情況下描述一個錯誤。在這種情況下，可以認為場景已經隱含在問題之中了。

不同類型的問題要素分布如圖5所示。圖5(b)展示了樣本中含有不同要素的問題比例。從中可以看出，大部分問題都有場景描述(77.8%)和代碼(61.3%)。但不同類型問題的要素分布卻不盡相同，如圖5(c)至圖5(i)所示。從圖5(i)中可以看出，通用知識類問題中含有場景要素的問題比例是最低的(54.5%)。這是因為通用知識類的問題通常是在學習而不是工作過程中產生的，而學習過程常常會缺乏具體的場景。

含有代碼要素的問題比例在不同的類型中差別很大：代碼要素在可行性分析類和解決方案規劃類的問題中比例遠遠低于其在總體中的比例，分別是34.9%和37.5%；實現類、評估類和通用知識類的問題比例則和總體相當，分別是54.4%、66.7%和56.1%；而剩下的糾錯和改進類的問題則普遍含有代碼要素，其比例分別是86.1%和70.6%。這種現象是由于可行性分析類和解決方案規劃類的問題通常是在實現之前發生的，這個階段幾乎沒有代碼可以展示。但是圖2所示流程僅僅是個通用過程，事實上很多項目中不同的階段是同步進行的。例如編號為17237287的問題“how can I wait 10 second without locking UI in Android”中，作者已經編寫了一些代碼，但是對于代碼中的關鍵功能——在不鎖定UI的情況下等待10秒——是否可以實現感到疑惑。因此即使是可行性分析類和解決方案規劃類的問題也擁有一定比例的代碼要素。

解決方案規劃類和改進類的問題擁有更高的當前方案要素比例，分別是23.4%和39.2%。而這個要素在總體中的比例僅為5.7%。這個現象對于改進類問題是很直觀的，改進類問題就是在當前方案的基礎上尋求改進方案。而對于解決方案規劃類的問題，一般來說提問者已經有一個設想的方案了，他所疑惑的只是整體方案中的某些點。因此，他們會給出他們的當前解決方案以得到更合適的答案。

圖5 不同類型問題中的要素分布

含有錯誤要素的問題比例在糾錯類問題中特別高，達到了54.6%(總體中僅為19.1%)。這個現象很好解釋，糾錯類問題需要提問者說清楚他所遇到的錯誤，而直接提供錯誤內容是最容易、最直接的方式。

3.3 交互行為

當用戶想要回答某個問題的時候，常常會出現不能理解問題的情況。這時候，他們會采取一些行動試圖獲得足夠的信息以回答問題。最常見的和提問者的交互方式就是在問題下面編寫評論。而提問者則通常會通過修改問題本身或者回復更多的評論來回應。和問題一樣，如果答案中有什么不清楚的地方，類似的行為也會在答案的評論中發生。

對于編程相關的問題，本文發現了一些特定的交互行為：

(1) 澄清意圖

一個問題的意圖不總是清晰明確的，此時回答者會請求提問者對問題的意圖進行詳細解釋。除此以外，回答者也有可能給出兩個猜想詢問是否是其中之一。例如，在編號為263348的問題“Best Practice - Swing, Database Access”中，有人評論道“Are you asking … ? Or are you asking…?”。

(2) 尋求要素

對于回答者來說，如果問題缺少了某些必要的成分將很難給出準確的答案，因此他可能會直接請求給出某種問題要素。

(3) 澄清要素

在某些問題中，問題要素存在但是描述得不夠清楚，從而造成回答者對于這些要素感到困惑。此時回答者會要求提問者澄清這些要素。提問者可以通過在代碼中添加注釋或者貼出異常定義等方式來進行澄清。

(4) 澄清術語

有些問題中提問者使用的術語可能具有歧義，此時回答者會請求提問者給出術語的準確定義。

(5) 提供參考

回答者有時會提供一些參考資料給提問者使其能更好地理解問題。例如，在編號為10228682的問題“how to change the location of a value in a list in a hashmap in Java”中，有用戶評論道“Maybe I didn’t get your question …, From the API document…”。在API文檔的幫助下，提問者知道了他所面臨的問題的基礎知識從而能提供更多有用的信息。

(6) 改善表述

問題的表述方式對于某些要素(尤其是代碼)是很重要的。但是冗長的文字描述和復雜的代碼會使得其他用戶很難抓住其中的關鍵信息。因此其他用戶會建議提問者以更好的方式表達他的問題，比如高亮關鍵語句或者省略不必要的代碼段。

(7) 嘗試

回答者會建議提問者進行一些嘗試后再給出反饋，從而使其能夠更好地理解問題。

(8) 解釋

回答者有時會向提問者解釋一些知識。此類行為常常在回答問題的時候發生，以幫助提問者理解答案。有時候在問題中也能觀察到這種行為，此時其目的和提供參考類似。

(9) 分步建議

回答者給出分步建議并在每一步后得到反饋以幫助提問者解決問題。

(10) 質疑問題

在一些少見的情況下，其他用戶會認為問題本身是沒有意義的。此時他們會和提問者在評論中對問題進行討論。例如，在編號為10799170的問題(Making an SSL http for localhost)中，雖然問題是想知道如何實現安全協議，但評論中有一條寫著“… If its localhost web app, why does it need to be secure http?”來質疑問題本身是否有意義。

圖6展示了含有這些交互行為的問題比例以及在各個類型的問題中各自的比例。從圖6(b)中可以看出，解釋是回答者最常采取的行為，在總體中占到34.5%。這個現象表明答案常常是不夠清楚的，專家需要對答案進行額外的解釋以幫助提問者理解答案并解決問題。除了解釋以外，澄清意圖、尋求要素、提供參考和嘗試也是很常見的行為，其在總體中的比例分別是18.1%，21.9%，24.7%以及21.2%。前三類行為是用來完善問題的。數據表明，超過五分之一的問題被要求補充要素。澄清意圖和提供參考則是為了搞清問題的意圖，其中前者是直接詢問這個意圖，而后者則是用參考來啟發提問者。在答案能夠直接通過參考資料給出的時候，提供參考也是一種在評論中直接回答問題的方式，這也是為什么含有提供參考的問題比例在通用知識類問題中相對較高了，達到了28.8%。

嘗試這種行為也是被用來獲取關于問題更多信息的。有時候提問者很難完整地描述他所遇到的問題，甚至不知道如何提供更多的信息。此時，專家需要指導提問者進行一些嘗試并貼出結果作為參考。然而通過評論施行此類行為非常低效。雖然從數據來看這類行為是比較重要的，但是目前SO并沒有一個很方便的功能來輔助這類行為。盡管嘗試這類行為被廣泛使用，在通用知識類的問題中卻并不常見，其比例僅為7.6%。這是因為通用知識類的問題一般來說缺乏實踐，比如一個詢問Java變量訪問策略的問題不需要進行嘗試。

澄清術語和表達建議是被使用的最少的行為，其在總體中的比例為1.9%和3.6%。澄清術語是為了解釋一個術語，但是在大多數情況下，問題中的術語是足夠清楚的。即使術語本身有二義性，結合問題的上下文，也能推斷出這個術語在問題中的含義。表達建議是為了修飾問題的表述方式，包括語言、排版等，常見的例子是要求提問者修改代碼以突出其中的關鍵部分。此類行為能幫助專家更快找到問題中的有效信息，但是即使問題的表述不夠好，專家還是能夠根據已有的問題給出合適的答案。因此，并不是所有表述不好問題中都有表達建議類的行為發生。

圖6 不同類型問題中的交互行為分布

除了行為分布，本文還分析了交互行為對于評分的影響情況。由于交互行為是由回答者引導以回答問題的，本文僅分析了其對答案評分的影響。表3展示了每一類問題中擁有不同交互行為的問題的最佳答案(標記為已接受的答案，如果沒有則為最高評分的答案)平均分的標準差。標準差越大意味著不同交互行為對答案產生的影響越大。從表中可以看出，評估和通用問題的最佳答案得分標準差較大，也就是說不同的交互行為對于這兩類問題的影響較大，因此本文對這兩類問題進行了重點分析。

表3 每類問題中含有不同交互行為的最佳答案平均得分的標準差

圖7展示了評估和通用知識類問題中含有各類交互行為的問題的最佳答案的平均得分與這兩類問題的最佳答案的平均得分的差值。從圖中可以看出，在評估類問題中，擁有交互行為的問題普遍有更高評分的最佳答案。而在所有交互行為中，澄清意圖和尋求要素這兩個意圖能大大提高答案的得分。這表明對于評估類問題，意圖和要素可能是最重要的元素。

不同于評估類問題，尋求要素這種行為對于通用知識類問題的貢獻就非常小了。而擁有澄清意圖行為的問題甚至擁有更低的平均得分。在通用知識類問題中，最突出的行為是質疑問題。這可能是由于通用知識類的問題常常沒有標準答案而只是個人喜好的不同而已。例如，對于詢問為什么Vim比Emacs好的問題，就可能被Emacs的擁護者質疑其意義。但是，這類問題的答案可以詳細比較各自的好壞以及給出選擇的依據，從而得到雙方支持者的贊同而得到更高的得分。

圖7 評估類和通用知識類問題含有各類交互行為的問題最佳答案平均分偏差

4 討 論

本文探究了軟件開發在線問答網站上問題的三個方面：類型、要素和交互行為，從1 001個問題中收集數據并發現了不同類型的問題，分析了問題類型和其要素以及交互行為的關系。根據分析結果，可以給此類網站的使用者提出一些使用指導，給其開發者一些建議，還可以給試圖開發自動化問答工具的研究者一些啟發。

4.1 對提問者和回答者的指導

本文的研究顯示不同類型的問題傾向于不同的要素。提問者首先應該明確自己詢問的是哪類問題，從而有傾向性地提供重要的要素。場景作為對提問者面對的情況的描述，對幾乎所有類型的問題都很重要，即使是通用知識類的問題也有很高的比例含有場景描述。提問者應該描述清楚他們問題的場景。場景以外的其他要素的重要性則取決于問題的類型。可行性分析類的問題需要描述期望；解決方案規劃類的問題需要描述可能方案；實現類的問題中可能方案也比較重要；糾錯類問題則需要描述清楚錯誤內容；而改進類問題則對當前方案要求比較高；實現類、糾錯類、評估類和改進類同時都要求給出代碼。

對于回答者而言，本文的研究結果也能給予他們一定的指導。解釋是最常見的交互行為，這也意味著問答網站上的回答常常會缺失詳細的信息。因此回答者在回答問題的時候，應該提供更具體內容，而不是在評論中再對答案進行解釋。澄清意圖和尋求要素這兩種行為是回答者在回答問題之前直接向提問者索求需要的信息，這兩種行為也很常見。也就是說，對于想要在SO上回答問題的新人來說，當對問題有任何疑惑時，應該直接詢問而不是猜測問題的意思。而提供參考和嘗試是兩個偏向實踐的幫助回答者理解問題的方法，在對問題有疑惑時，即使采取這兩種方法可能并不能及時得到反饋，也應該將他們納入可選的行動之中。

4.2 對軟件開發在線問答網站開發者的建議

數據表明，接近80%的問題擁有場景這個要素，并且得分越高的問題中含有場景要素的比例越高。這說明場景對于澄清問題有著非常重要的作用。然而，在許多問題中，場景和其他諸如環境、現有方案等混雜在一起。為了更清楚地呈現問題，可以設計一個特殊的UI元素以強調問題的場景(例如使用深色背景)。此外含有場景的問題擁有更高的平均得分，在用戶輸入問題時也可以提供相應的UI鼓勵用戶明確問題的場景。例如在提問頁面上提供專門的輸入框讓用戶闡述問題場景。

另一方面，提問者和回答者的交互方式也是可以改進的。在現有的機制中，評論幾乎是雙方交流的唯一選擇。這種方式對于問詢類的行為(例如澄清意圖和尋求要素)來說是很方便的，對于提供諸如參考材料的網址或者簡單的解釋來說也有一定的效果。然而，對于嘗試、分步建議這兩種同樣很重要的交互方式來說，通過評論進行頻繁的交流就顯得沒那么高效了。問答網站可以提供即時聊天系統供用戶使用。更進一步，如果支持更豐富的內容交互方式(例如遠程桌面控制)就能幫助用戶更有效地進行交流了。

4.3 對開發自動化問答工具的啟發

自動化問答工具其實和問答網站上的問答不盡相同。理想情況下，當程序員使用問答工具時，他應該只需要輸入一個問句而不是對問題的詳細描述就能得到答案。而回答問題所需要的必要信息則應該有工具自動收集。

本文發現問題類型是問題的一個非常重要的元素。問題的類型和問題要素、交互行為都有著比較高的相關度。因此，問答工具需要能夠識別出用戶的問題類型。為了實現這個目的，NLP(自然語言處理)技術是可以考慮的方向。例如利用自然語言的語法模式來識別問題類型。研究者可以通過人工定義或者機器學習的方式得到不同類型問題的語法模式。當用戶提出一個問題時，工具就可以將問題和某個模式進行匹配從而得到問題的類型。

知道問題的類型后，就需要去收集回答問題所需的必要信息，也就是問題要素。下面列舉了一個問答工具可以收集問題要素的三個途徑。首先就是用戶提出的問題本身，自然語言處理可以在這里被進一步使用。然而，一個簡單的問句所包含的信息量是遠遠不夠的，因此工具需要通過其他兩個途徑獲取更多的信息。第二個途徑是自動化的抓取信息。工具可以利用IDE插件等技術監控用戶在編程中所采取的行動以及行動的結果，從而獲得場景、環境、代碼、錯誤信息等要素。第三個途徑則是交互式地向用戶詢問。工具可以根據上下文要求用戶手動提供更多的信息。在交互式詢問的過程中，工具除了簡單地向用戶索求信息外，工具還可以采取更多的行為。跟人類回答者類似，工具也可以向用戶提供一些參考材料以啟發用戶提供信息。而跟問答網站不一樣的是，自動化工具可以以更為豐富和便利的形式向用戶提供這些參考材料。此外，工具還可以建議用戶進行一些嘗試并自動采集嘗試過程中的數據，從而大大提高收集數據的效率。

4.4 威脅因素

本文的研究設計有一定的局限，會威脅到本文的結果。

第一是本文采用的數據集是StackExchange官方發布的，這個數據集中并沒有包含SO上的所有信息。一些敏感信息會在數據集發布前被過濾。不過，大部分被過濾的信息都是一些個人隱私數據(比如昵稱等)，這些數據對本文的研究影響甚微。

二是收集怎樣的數據是由本文的第一、第三兩位作者通過先導研究總結的，這受限于兩位作者的所學。然而，為了讓數據盡量全面，本文進行了多而完善的討論。任何對于一個問題的不確定或者不一致的看法，都會邀請其他資深研究人員或者SO使用者共同討論。同時，在用以收集數據的問卷設計完后，還邀請了一位博士和一位SO使用者試用并幫助改進問卷。通過這些機制，本文收集到了較為全面和公允的數據。

第三是在深入分析過程中，本文使用的是問卷形式人工收集數據。為了最小化因個人知識的局限而導致的偏差，本文采取了一些額外的措施。在收集數據之前，進行了2小時的培訓，對問卷中的每個選項都進行了詳細的解釋。除此之外，本文的第一、第三作者以及參與先導試驗的兩位研究者組成了一個顧問小組。當參與收集數據的人員對某個問題有任何疑慮時，至少可以找到一位顧問幫助他分析問題。在極少數情況下，如果顧問本人對問題不確定的話，整個顧問小組就一起討論分析問題。

5 相關工作

互聯網在軟件開發中起到了越來越大的作用，在線問答網站也被程序員越來越多得使用，StackOverflow則是此類網站中最具代表性的一個。因此，針對SO的研究已有很多。Christoph Treude等[2]分析了StackOverflow的數據并對用戶提出的問題進行了分類并探索哪些問題被回答得很好，哪些問題又沒有被回答。Seyed Mehdi Nasehi等[3]試圖找出SO上好的代碼樣例有什么特點。他們的結論是與樣例代碼一起給出的解釋和代碼本身同等重要。Amiangshu Bosu等[4]研究了SO上的表彰評分系統并對想在SO上獲得更高評價和評分的新用戶給出了一些建議。Blerina Bazelli等[5]則使用Linguistic Inquiry和Word Count(LIWC)分析SO上開發者的個人特質。他們發現獲得最高評價的作者(使用者)相比低評價的使用者更為外向。此外，擁有高評分問題或答案的作者更少地表達他們的負面情緒。Benjamin V. Hanrahan等[1]專注于構建困難問題和專家的指示器以及探究復雜問題是如何被多名專家處理和分發的。Dennis Schenk等[6]評估了SO上的知識經濟系統的狀態。Shaowei Wang等[7]展示了問題、開發者及其行為的分布以及通過LDA生成的開發者所屬話題的分布情況。Xin Xia等[8]提出了名為TagCombine的自動標簽推薦方法以分析軟件信息相關頁面的對象。他們使用SO評估了這個方法并得到了更好的標簽推薦結果。Anton Barua等[9]使用LDA分析了SO上的文本內容并得到了SO的一些話題和確實。

除了StackOverflow以外，另一些網站也被用來分析用戶的行為。MathOverflow是一個類似于StackOverflow的網站，只是其目標用戶是數學家或者數學研究者。Yla R. Tausczik等[10]在流程的層次理解了MathOverflow上的協作活動并量化不同協作活動對于解決方案質量的影響。Yahoo!Answers是另一個被用于研究的問答網站。Gyongyi Z等[11]分析了Yahoo!Answer的10個月的數據。他們研究了問答系統中的活動層次、角色、關注點、連接性和名聲系統并討論了此類服務的不同方面和可能的發展。Lada A. Adamic等[12]也對Yahoo!Answers進行了研究。他們分析了論壇分類并根據內容特點和用戶間的交互模式進行了聚類。

跟上述的所有研究不同的是，本文的研究關注于人類回答者能從軟件開發在線問答網站上會采取那些行為來回答問題。由于人類可以獲得的信息很難使用自動化的手段去抽取，而這些信息對于理解用戶的行為又至關重要。因此，本文通過人工閱讀的方式分析了SO上的1 001個問題。最后，本文還為SO的用戶、開發者以及問答系統的研究者提供了一些指導和建議。

6 結 語

互聯網的發展使得開發者越來越多地求助于軟件開發在線問答網站解決自己遇到的問題，而StackOverflow是在程序員參與社會化學習中使用的最為廣泛的問答網站[13]。SO上張貼的巨量的問題和答案提供了研究編程領域提問者-回答者交互行為研究的很好資源。本文對SO上的問題進行了閱讀并從中收集數據，并對數據進行了細致分析，一共發現了7個不同的問題類型。不同的問題類型又對不同的問題要素有所偏好。此外，回答者會采取不同的交互行為去更好地理解問題并給出答案。根據分析結果，本文針對軟件開發在線問答網站的使用者、開發者以及問答系統的研究者分別給出了指導和建議。

將來，我們會根據本文的分析結果構建一個自動化的問答工具。這類工具將會在開發者遇到困難時幫助其解決以提高開發效率。

[1] Hanrahan B V, Convertino G, Nelson L. Modeling problem difficulty and expertise in stackoverflow[C]//Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work Companion. ACM, 2012: 91-94.

[2] Treude C, Barzilay O, Storey M A. How do programmers ask and answer questions on the web?: Nier track[C]//Software Engineering (ICSE), 2011 33rd International Conference on. IEEE, 2011: 804-807.

[3] Nasehi S M, Sillito J, Maurer F, et al. What makes a good code example?: A study of programming Q&A in StackOverflow[C]//Software Maintenance (ICSM), 2012 28th IEEE International Conference on. IEEE, 2012: 25-34.

[4] Bosu A, Corley C S, Heaton D, et al. Building reputation in stackoverflow: an empirical investigation[C]//Proceedings of the 10th Working Conference on Mining Software Repositories. IEEE Press, 2013: 89-92.

[5] Bazelli B, Hindle A, Stroulia E. On the personality traits of stackoverflow users[C]//2013 IEEE International Conference on Software Maintenance. IEEE, 2013: 460-463.

[6] Schenk D, Lungu M. Geo-locating the knowledge transfer in StackOverflow[C]//Proceedings of the 2013 International Workshop on Social Software Engineering. ACM, 2013: 21-24.

[7] Wang S, Lo D, Jiang L. An empirical study on developer interactions in StackOverflow[C]//Proceedings of the 28th Annual ACM Symposium on Applied Computing. ACM, 2013: 1019-1024.

[8] Xia X, Lo D, Wang X, et al. Tag recommendation in software information sites[C]//Proceedings of the 10th Working Conference on Mining Software Repositories. IEEE Press, 2013: 287-296.

[9] Barua A, Thomas S W, Hassan A E. What are developers talking about? an analysis of topics and trends in stack overflow[J]. Empirical Software Engineering, 2014, 19(3): 619-654.

[10] Tausczik Y R, Kittur A, Kraut R E. Collaborative problem solving: A study of mathoverflow[C]//Proceedings of the 17th ACM conference on Computer supported cooperative work & social computing. ACM, 2014: 355-367.

[11] Gyongyi Z, Koutrika G, Pedersen J, et al. Questioning yahoo! answers[R]. Stanford InfoLab ,2007.

[12] Adamic L A, Zhang J, Bakshy E, et al. Knowledge sharing and yahoo answers: everyone knows something[C]//Proceedings of the 17th international conference on World Wide Web. ACM, 2008: 665-674.

[13] Vassileva J. Toward social learning environments[J]. Learning Technologies, IEEE Transactions on, 2008, 1(4): 199-214.

RESEARCH ON INTERACTION PROCESS OF QUESTION AND ANSWER IN SOCIAL SOFTWARE DEVELOPMENT

Wang Hai Peng Xin Yu Han Zhao Wenyun

(SchoolofSoftware,FudanUniversity,Shanghai201203,China) (ShanghaiKeyLaboratoryofDataScience,FudanUniversity,Shanghai201203,China)

Online Q & A Web site software development, solve the problem of the process is not a simple question and answer, and often contains a complex interactive process. A deep understanding of the Q & A features of the Q & A Web site and its interactive processes are of great importance in improving the quality of questions and answers, improving interaction efficiency, and developing related automation aids. From the purpose and intent of the problem in StackOverflow, the basic elements, and the interaction to carry out research, sampling and analysis of 1 001 problems, summed up the problem of 7 types, 8 elements and 10 types of interaction. According to the research results, the corresponding suggestions are put forward to users, developers and researchers of the Q & A website.

Software development Question and answer StackOverflow Social learning Interaction

2016-05-13。國家自然科學基金項目(61370079)。王海，碩士生，主研領域：軟件維護。彭鑫，教授。于涵，碩士生。趙文耘，教授。

TP311

A

10.3969/j.issn.1000-386x.2017.05.001