王 海 彭 鑫 于 涵 趙文耘

(復(fù)旦大學(xué)軟件學(xué)院 上海 201203) (復(fù)旦大學(xué)上海市數(shù)據(jù)科學(xué)重點實驗室 上海 201203)

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

王 海 彭 鑫 于 涵 趙文耘

(復(fù)旦大學(xué)軟件學(xué)院 上海 201203) (復(fù)旦大學(xué)上海市數(shù)據(jù)科學(xué)重點實驗室 上海 201203)

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

軟件開發(fā) 問答 StackOverflow 社會學(xué)習(xí) 交互

0 引 言

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

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

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

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

RQ1：按照提問的目的進(jìn)行區(qū)分，軟件開發(fā)人員經(jīng)常會問到哪些不同類型的軟件開發(fā)問題？

RQ2：一個完整、清晰的軟件開發(fā)問題陳述應(yīng)當(dāng)包含哪些基本要素？

RQ3：問答雙方經(jīng)常采取哪些交互行為和交互方式來進(jìn)行問題澄清和回答？

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

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

1 背景介紹

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

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

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

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

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

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

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

2 研究過程

2.1 概 覽

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

2.2 數(shù)據(jù)準(zhǔn)備

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

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

本文還統(tǒng)計了問題和答案的評分?jǐn)?shù)據(jù)。所有問題的平均評分是1.59，標(biāo)準(zhǔn)差是9.46。所有答案的平均評分是2.07，標(biāo)準(zhǔn)差是10.1。圖1(a)和圖1(b)展示了全集中問題和答案的評分分布。所有擁有“已接受”答案的問題的平均評分是2.07，而所有“已接受”的答案的平均評分是3.31。

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

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

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

2.3 前導(dǎo)研究

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

表1 全集和樣本集的統(tǒng)計數(shù)據(jù)

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

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

2.4 深入分析

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

? 采樣的全集是樣本集。

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

? 每層的抽樣都是隨機(jī)抽樣過程。

根據(jù)以上規(guī)則，本文一共抽樣選取了1 001個問題。每個評分區(qū)間的問題數(shù)量如表2所示。

表2 各個評分區(qū)間的問題數(shù)量

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

3 研究結(jié)果

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

3.1 問題類型

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

圖2 常見的困難解決流程

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

(1) 可行性分析

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

(2) 解決方案規(guī)劃

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

(3) 實現(xiàn)

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

(4) 糾錯

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

(5) 評估

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

(6) 改進(jìn)

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

(7) 通用知識

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

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

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

圖3 問題類型分布

3.2 問題要素

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

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

(1) 當(dāng)前方案(Current Solution)

這是對于當(dāng)前面對的問題的已實現(xiàn)的方案。提問者可以介紹其設(shè)想、設(shè)計、算法或者在解決方案中使用的方法。

圖4 問題要素及其關(guān)系

(2) 場景(Scenario)

這是問題產(chǎn)生的場景。它可以是由當(dāng)前方案招致的真實場景，也可以是在可行性分析或解決方案規(guī)劃時所設(shè)想的場景。

(3) 錯誤(Error)

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

(4) 輸出(Output)

這是在場景產(chǎn)生的輸出內(nèi)容。

(5) 環(huán)境(Environment)

這是場景發(fā)生的環(huán)境，比如操作系統(tǒng)、網(wǎng)絡(luò)條件等。

(6) 期望(Expectation)

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

(7) 可能方案(Possible Solution)

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

(8) 代碼(Code)

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

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

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

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

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

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

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

3.3 交互行為

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

對于編程相關(guān)的問題，本文發(fā)現(xiàn)了一些特定的交互行為：

(1) 澄清意圖

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

(2) 尋求要素

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

(3) 澄清要素

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

(4) 澄清術(shù)語

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

(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文檔的幫助下，提問者知道了他所面臨的問題的基礎(chǔ)知識從而能提供更多有用的信息。

(6) 改善表述

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

(7) 嘗試

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

(8) 解釋

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

(9) 分步建議

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

(10) 質(zhì)疑問題

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

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

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

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

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

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

表3 每類問題中含有不同交互行為的最佳答案平均得分的標(biāo)準(zhǔn)差

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

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

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

4 討 論

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

4.1 對提問者和回答者的指導(dǎo)

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

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

4.2 對軟件開發(fā)在線問答網(wǎng)站開發(fā)者的建議

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

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

4.3 對開發(fā)自動化問答工具的啟發(fā)

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

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

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

4.4 威脅因素

本文的研究設(shè)計有一定的局限，會威脅到本文的結(jié)果。

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

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

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

5 相關(guān)工作

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

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

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

6 結(jié) 語

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

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

[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。國家自然科學(xué)基金項目(61370079)。王海，碩士生，主研領(lǐng)域：軟件維護(hù)。彭鑫，教授。于涵，碩士生。趙文耘，教授。

TP311

A

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