社交化软件开发问答中的交互过程研究

王 海 彭 鑫 于 涵 赵文耘

(复旦大学软件学院 上海 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