(1994-), 男, 博士生, 主要研究领域为软件质量保障, 软件缺陷预测
(1990-), 男, 博士生, 主要研究领域为实证软件工程
(1994-), 女, 硕士, 主要研究领域为软件测试
(1981-), 男, 博士, 助理研究员, CCF专业会员, 主要研究领域为软件演化与维护, 软件测试
(1979-), 男, 博士, 副教授, CCF高级会员, 主要研究领域为软件分析测试
(1974-), 男, 博士, 教授, 博士生导师, CCF专业会员, 主要研究领域为软件维护, 测试与分析
(1961-), 男, 博士, 教授, 博士生导师, CCF会士, 主要研究领域为程序设计语言, 软件分析与测试
郭肇强和刘释然为共同第一作者
技术债是一个指以牺牲长期代码质量为代价来实现短期项目目标的隐喻. 其中, 那些由开发者有意引入项目中的技术债被称为自承认技术债(self-admitted technical debt, SATD), 通常以代码注释的形式存在于软件项目中. SATD的存在给软件质量和鲁棒性带来了巨大挑战. 为了识别并且及时地偿还SATD来保障代码质量, 研究者从特性分析和识别模型两方面进行了大量研究并且取得了较大的进展. 与此同时, 相关研究工作中仍存在一些亟待解决的挑战. 对近年来国内外学者在该领域的研究成果进行系统性的总结. 首先, 描述自承认技术债的研究问题. 然后, 分别从特性分析和识别模型两方面总结相关的研究进展, 并对具体的理论和技术途径进行梳理. 接着, 简要介绍技术债的其他相关技术. 最后, 指出目前该领域研究过程中面临的挑战并给出建议的研究方向.
Technical debt is a metaphor that refers to sacrifice the long-term code quality to satisfy the short-term goals. In particular, the technical debts introduced intentionally by developers are called self-admitted technical debt (SATD), which usually exist in software projects in the form of code comments. The SATDs bring great challenges to quality and robustness of software. In order to facilitate finding and paying back them as soon as possible for assuring software quality, in recent years, great progress has been made in the field of investigating the characteristics of SATD and proposing the identification models for SATD. Nevertheless, it is still challenging to apply them in practice. This paper offers a systematic survey of recent research achievements in SATD. First, the research problems are introduced in this field. Then, the current main research work is described in detail. After that, related techniques are discussed. Finally, the opportunities and challenges in this field are summarized and the research directions in the future are outlined.
软件开发团队在进行软件产品的研发时有一个共同的目标, 那便是能够在指定的(时间或者资金)预算内交付高质量无缺陷的软件产品[
技术债是一种隐喻, 其定义为以牺牲长期的代码质量为代价来换取实现短期的项目目标[
根据技术债的引入方式, 技术债可以分为无意引入和有意引入两个主要类别.
(1) 无意引入的技术债(TD introduced unintentionally). 开发者由于缺乏经验而书写的低质量的代码或者是疏忽引入的技术债, 他们实际上并没有意识到已经引入了技术债[
(2) 有意引入的技术债(TD introduced intentionally). 在权衡短期效益与长期维护成本之后, 开发者主动引入一类技术债来临时满足当前软件开发的需求, 例如开发者硬编码若干个参数来临时满足某个功能的正常运行并抢先上架软件来获取用户和市场. 由于开发者在引入这类技术债时明确知道它们的存在, 因而其也被称为自承认技术债(self-admitted technical debt, SATD)[
自承认技术债是可以进行主动溯源的, 并且对其进行移除可以明显提升软件的质量. 此外, 这类技术债在项目中普遍存在(例如, 在Potdar等研究的项目中, 有超过30%的文件中包含SATD[
本文主要对自承认技术债的已有研究工作进行综述. 为方便表述和阅读, 本文接下来的部分均使用SATD来指代自承认技术债. 从2014年首次提出SATD的概念到2020年8月为止, 学术界已有40多篇文献从不同的角度对SATD进行研究. 据我们所知, 目前SATD领域的文献几乎全部发表于外文国际期刊或会议. 国内学术界对该领域的介绍较为稀少, 所有的国内文献均是关于技术债(而非SATD)的研究[
本文在第1节首先概述SATD识别领域主要的研究问题; 接着在第2节说明本综述的文献检索方式和文献汇总信息; 然后在第3节介绍对SATD的特性分析实证研究; 第4节介绍对SATD的识别模型的研究; 接着在第5节介绍技术债识别领域的其他研究方法; 在第6节分析SATD领域的研究所面临的挑战; 最后在第7节总结本文的内容.
本小节通过提问的方式介绍SATD的相关知识概要, 包括对SATD的定义、研究SATD的原因、SATD的产生原因和主要的研究方式.
软件项目在维护和演化过程中总是存在着一对矛盾的客体. 一方面, 开发团队或组织的目标和宗旨是在时效期间内能够及时地交付高质量的软件制品; 另一方面, 软件在被开发和迭代的过程中会由于诸多不可预期的因素而导致开发者编写无法满足实际需要的低质量代码(not-quite-right code). Cunningham[
SATD是技术债家族中的一种. 这类技术债是被项目的技术人员(如开发者或管理者)所承认的. 换句话说, 他们知道项目中SATD的存在, 甚至也知道具体的债务内容、与债务相关的代码位置、债务产生的原因以及偿还债务的解决方案等, 因为这些SATD是被人为有意地添加到项目中的用以临时满足当前的开发需要. SATD涵盖了项目中各方面存在的问题, 包括糟糕的架构设计、不正确的测试代码、缺失的文档说明、有缺陷的代码片段、算法次优实现(如硬编码)等. 为了便于后期进行SATD的移除, 开发者会主动地在项目中(如代码里)标注这些债务.
结合现有研究, 本小节总结出人们研究SATD主要的原因.
首先, SATD的存在会给软件项目带来负面的影响[
(1) 降低软件质量[
(2) 增加维护成本[
其次, SATD在软件项目中扮演者着重要角色, 因此不能够忽略对其进行研究. 其重要性体现在以下两点.
(1) 普遍性[
(2) 不可替代性[
在软件演化过程中, 许多因素都会促使开发者在项目中主动引入SATD来暂时满足某些短期的目标. 根据对现有文献中总结, SATD主要由如下原因造成.
(1) 项目成本被缩减[
(2) 快速响应客户需求[
(3) 尽快抢占市场[
(4) 发布日期临近[
(5) 尽快实现新功能[
SATD在被开发者引入项目中时已经被其主动地记录在项目里. 由于代码注释有助于记录、交流和理解程序中出现的各种问题, 并在程序演化中起着重要作用[
Examples of code comments that indicate self-admitted technical debt
自承认技术债的注释样例
SATD实例 | 文献来源 |
// EATM Demand create metadata; needs to depend on processing mode… | [ |
// TODO this is such a hack it is silly | [ |
TODO: this isn’t quite right but it’s ok for now | [ |
/* TODO: really should be a separate class */ | [ |
//I can’t get my head around this; is encoding treatment needed here? | [ |
//FIXME: to be moved to ApiResponseHelper | [ |
Potdar等人[
综合现有与SATD相关的文献, 学术界对该领域的研究主要集中在分析SATD的相关特性[
理解SATD的特性能够帮助我们更有效地对其进行管理, 从而更好地对软件质量提供保障. 目前研究者们进行大量的实证研究主要从
(1) 种类[
(2) 分布[
(3) 根因[
(4) 移除[
(5) 影响[
The dimension of comprehension for self-admitted technical debts
对自承认技术债的理解维度
本小节对SATD识别方法的流程进行介绍. 根据对现有文献的总结, 多数研究者将SATD的识别视为文本的二分类任务[
Overview of self-admitted technical debts identification
识别SATD的方法流程概览
(1) 抽取注释. 这一步从项目代码中提取注释数据. 首先把项目代码下载下来; 然后使用现有工具(如 JDeodorant[
(2) 文本预处理. 代码注释大多是用自然语言文本构成, 其结构和形式复杂多样[
(3) 构建分类模型. 研究者在这一步使用各种技术来构建SATD分类模型, 包括但不限于有监督的自然语言处理技术[
(4) 评估分类模型. 研究者在这一步使用测试数据来评估模型的有效性. 因为模型会输出分类结果, 所以常用的评估指标有精确率(precision)、召回率(recall)和其调和平均数F1等.
经过上述步骤, SATD识别模型会对测试项目中的每个注释实例预测出一个类别(SATD或者non-SATD). 这个结果可以向开发者推荐项目中存在的SATD并提醒他们及时对其进行处理. 需要说明的是, 对注释进行文本预处理(
对SATD的研究近年来成为软件质量保障和软件维护领域的热点研究问题. 本文的参考文献力图覆盖7年来与SATD相关的主要研究工作, 同时包含技术债领域的其他相关研究方法的主要文献. 具体来说, 本文使用以下的步骤来进行相关文献的检索和筛选.
(1) 检索目标: 谷歌学术搜索引擎(Google scholar)、DBLP Computer Science Bibliography、ACM Digital Library、IEEE Xplore Digital Library以及Springer Link Online Library等论文数据库. 检索内容主要包括软件工程-系统软件-程序设计语言方向的国际一流会议(ESEC/FSE、ICSE、ASE等)和一流期刊(TSE、TOSEM等)以及其他重要的会议和期刊如MSR、ICSME等录用的文章.
(2) 检索关键词: 包括“self-admitted technical debt”以及“technical debt”与“code comment(s)”的组合. 我们在目标数据库中对文献的题目使用上述关键词进行简单搜索.
(3) 检索起止时间: SATD在2014年被提出, 因此我们检索2014–2020年共7年之间的文献.
(4) 文献审查: 首先对检索出来的文献进行人工筛选, 去除不符合研究主题的文献以及从不同数据库中检索出的重复文献; 然后检查选中论文中的参考文献列表补充上未检索到的文献; 最后在第2.2节中对所选文献进行汇总.
经过文献的检索与筛选, 本文收集了SATD领域的学术论文共41篇. 这些研究论文将会按照其内容分类分别在第3节和第4节进行重点介绍. 对于其他种类的技术债的相关研究, 我们在第5节中对其进行分类和介绍.
Illustration of literature by years
SATD的相关研究文献的年代分布
Illustration of literature by publications
SATD的相关研究文献的出版物分布
Timeline of self-admitted technical debt-related researches
SATD相关研究的进展时间轴
本节介绍对SATD的特性进行实证研究的进展. 由于现有文献从不同的角度切入研究, 本节对其分类并主要从SATD的种类、分布、根因、移除和影响5部分展开介绍. 然后汇总当前研究的用到的数据集.
对技术债的分类研究是一项重要的工作, 这是因为不同类型的SATD对应有不同的解决方法. 在确定技术债所属的种类后可以为其量身定制的合适的解决方案来偿还该债务[
2014年, Alves等人[
据我们所知, 现有已知SATD种类类别(如需求债)基本上来源于Alves等人[
The summary of types of self-admitted technical debt in current researches
现有研究中SATD的种类总结
类型
|
定义概述[ |
高频率关键词[ |
● 出现某类SATD的场景[ |
● 预防措施 &
|
需求债
|
代码中的方法、类或程序不完整 | Scope, Business, Artifact, Conception, Requirements, Specification, ... | ● 仅实现部分需求
|
● 定义明确的需求
|
设计债
|
代码中存在设计问题(如方法过长) | Component, encapsulation, design, method, metric, code, coupling, Cohesion, Class, clone, Polymorphism, Object, ... | ● 违反面向对象设计原则
|
● 遵循项目计划
|
架构债
|
架构中存在的问题 | Coupling, Aspect, Base, Component, Environment, Gui, Function, architecture, Software, System, Query, package, Procedure, Polymorphism, Library, Interface, Hierarchy, Connector, Layer, Link, Message, Module, Tier, … | ● 违反模块性
|
● 遵循明确的项目流程
|
算法债
|
算法实现没有达到最优情况 | Algorithm, optimize, … | ● 次优的算法逻辑实现 | ● 代码标准化
|
代码债
|
代码存在易读性问题 | Algorithm, Code, Component, Deployment, Gui, Query, class, method, file, clone, Metric, Logic, Language, Compilation, Declaration, Variable, Exception, Legibility, Loop, Performance, Rapidity, Release, Version, Speed, ... | ● 不必要的重复和复杂代码
|
● 代码评估
|
文档债
|
代码中缺少说明文档 | Documentation, Diagram, Use case, Template, Model, Manual, Metadata, Remarks, Survey, ... | ● 丢失文档
|
● 遵循项目计划
|
兼容债
|
代码依赖版本不兼容 | Compatibility, … | ● 不成熟的依赖 | ● 定义明确的体系结构
|
缺陷债
|
代码实现中存在缺陷 | Bug, Deployment, defect, Error,
|
● 修复软件系统中缺陷的
|
● 培训
|
构建债
|
代码构建复杂或者耗时 | Artifact, Aspect, Construction, Deployment, Environment, Polymorphism, Hierarchy, Compilation, Risk, Tool, ... | ● 构建无价值代码
|
● 遵循项目计划
|
测试债
|
缺少或者需要改进测试代码 | Test, Reliability, Precision, Coverage... | ● 测试覆盖率不足
|
● 创建测试用例
|
(1) 需求债(requirement debt)[
定义: 这类债务注释指出某个方法、类或者程序的结构不完整, 其中有部分的需求没有被实现或者仅仅是部分被实现. 同时, 一些需求虽然已经被实现但是不完全满足所有非功能性需求(如安全性、性能等)[
偿还: 按照要求将缺失的代码补充完整.
样例: 在如下样例中, 该注释指出缺少方法getClassname.
“/TODO no methods yet for getClassname” — [from Apache Ant][
(2) 设计债(design debt)[
定义: 这类债务注释指出了代码中存在设计问题如代码放错地方、缺少抽象层、方法冗长、实现太差、高耦合度的类或临时解决方案等. 可见, 所有的设计债都是非最优决策的结果[
偿还: 通过代码重构或者对其重新实现来解决.
样例: 在如下样例中, 该注释指出该方法设计太复杂需要进行拆分.
“TODO: - This method is too complex, lets break it up” — [from ArgoUML][
(3) 架构债(architecture debt)[
定义: 这类债务指出了代码架构中存在的问题. 大多数的架构债都表现出违反模块性的特点, 少数的架构债是由于使用了过时的技术导致的[
偿还: 通常来说软件架构很难改变, 开发者只能使调整项目本身代码以适应软件架构的特性.
样例: 在如下样例中, 该注释说明将代码移入自己的模块比较好.
“It would be good if these were moved into their own module…” — [from Camel][
(4) 算法债(algorithm debt)[
定义: 这类债务特指深度学习框架中的次优算法. 由于基于深度学习的项目通常比较消耗计算资源, 这类项目中的次优的算法会明显降低系统的效率[
偿还: 对相应的算法进行优化.
样例: 在如下样例中, 该注释说明需要对单元kCostPerUnit进行优化.
“TODO (zakaria): optimize kCostPerUnit” — [from TensorFlow][
(5) 代码债(code debt)[
定义: 这类债务注释指出了项目中难以阅读和理解从而维护难度较高的代码. 通过检查项目的源代码并且考虑与错误的编码实践相关的问题可以识别这种债务.
偿还:
样例: 在如下样例中, 该注释指出导致代码不可维护的问题.
“This will lead to very unmaintainable code. We absolutely do not want to have nested retries for different contexts.” — [from Hadoop][
(6) 文档债(documentation debt)[
定义: 这类债务注释标记了那些缺少文档说明支持或者文档质量较低的程序. 虽然这些程序可以正常工作, 但不能满足软件项目的某些质量标准的文档会导致不同的开发者产生代码理解上的困难.
偿还:
样例:
(7) 兼容债(compatibility debt)[
定义: 这类债务注释指出某项目的代码依赖于不能提供所有合格服务的其他项目, 即依赖版本不兼容. 这类债务的存在可能导致项目在随后的演化中产生更多代码变更[
偿还: 开发者需要更换依赖版本来解决此债务.
样例: 在如下样例中, 该注释指出代码会在装有CUDA 7.0.18的Linux系统上运行失败.
“Moved to common.cpp instead of including boost/thread.hpp to avoid a boost/NVCC issues (#1009, #1010) on OSX. Also fails on Linux with CUDA 7.0.18.” — [from Caffe][
(8) 缺陷债(defect debt)[
定义: 这类债务注释指出了代码中存在缺陷, 即该段代码中的预期功能实现错误. Bavota等人[
偿还:
样例:
“// Bug in above method” — [from Apache Jmeter][
(9) 构建债(build debt)[
定义: 在这类债务中, 项目的构建过程可能包含对客户来说非常不必要的代码以及包含运行定义错误的依赖项. 这些问题会导致该过程将变得不必要的缓慢.
偿还: 根据描述修正构建文件来移除这类技术债.
样例: 在如下样例中, 该注释指出了缺失显式依赖导致的问题.
“Compiling for Fedora revels a missing declaration for javax.annotation. Nullable. This is the result of a missing explicit dependency on…” — [from Hadoop][
(10) 测试债(test debt)[
定义: 这类债务注释指出当前代码中与测试相关的问题, 包括未运行计划的测试用例, 或测试套件中存在已知的缺陷(例如代码覆盖率低).
偿还: 实现缺失的测试用例或者改进有问题的测试套件.
样例: 在如下样例中, 该注释指出需要启动一些合适的测试.
“//TODO enable some proper tests!!” — [from Apache Jmeter][
根据上文对SATD种类的介绍以及对相关文献[
(1) SATD种类划分的依据. 在现有研究中, 研究者给出的是不同SATD种类的模糊定义(
(2) SATD种类划分的特点. 从当前研究SATD种类的文献[
(3) SATD种类之间的关联性. 虽然本文汇总出了10个种类的SATD, 但是在实际进行种类划分时存在一条注释同属于多个种类的情况, 即不同种类的SATD之间存在关联性. 现有文献中设计的关联性有: 1) 设计债与缺陷债. 文献[
The relationship between types of self-admitted technical debt
自承认技术债的种类之间的关联性
对SATD的分布进行量化有助于开发者明确地了解每种类型SATD对应问题的严重性、受关注程度[
The distributions of types of self-admitted technical debt in different researches
SATD在不同研究中的类型分布情况(%)
类型 | Maldonado等人[ |
Bavota等人[ |
Liu等人[ |
Mensah等人[ |
Li等人[ |
代码债 | - | - | - | ||
缺陷债 | 4−9 | 20 | 2−7 | - | 3 |
设计债 | 13 | 57−68 | 5 | ||
文档债 | 0−5 | 10 | 0−16 | - | 22 |
需求债 | 5−45 | 20 | 4−31 | - | 3 |
测试债 | 0−7 | 7 | 0−8 | - | 18 |
兼容债 | - | - | 0−35 | - | - |
算法债 | - | - | 6−21 | - | - |
架构债 | - | - | - | - | 7 |
构建债 | - | - | - | - | 6 |
2014年Potdar等人[
如第3.1节中所说, 研究者在对种类进行划分时存在差异性, 因此
SATD由开发者主动引入项目中, 在项目中演化一段时间后可能会被开发者偿还而从项目中移除.
The introduction and removal of self-admitted technical debt
自承认技术债的引入和移除
目前, 对SATD根因的研究文献较少, 主要的发现来自Potdar等人[
通常来说, SATD在被引入项目后是需要被移除的[
在Potdar等人[
根据2016年Bavota等人[
2017年, Maldonado等人[
2018年, Zampetti等人[
2019年, Maipradit等人[
同年, Iammarino等人[
研究SATD的影响可以对SATD的危害特性(如正向利息[
The summary of findings on the impact of SATD
对SATD影响的主要发现
年份 | 文献 | SATD的影响 |
2014 | [ |
SATD不会对代码的复杂性产生影响 |
2016 | [ |
SATD会对软件产生负面影响, 但是其影响并不是与缺陷有很强的关系, 而是会使系统变得复杂从而导致在将来很难对其进行变更 |
[ |
SATD会给软件系统的维护带来正向利息(positive interest, 即偿还债务的额外困难) | |
[ |
SATD会增加软件系统维护时的返工工作量(rework effort, 即为偿还债务需要修复的代码行) | |
2019 | [ |
SATD注释无法对消除系统架构分歧产生显著影响 |
2014年, Potdar等人[
2016年, Wehaibi等人[
Kamei等人[
Mensah等人[
2019年, Sierra等人[
上述对SATD进行实证研究结果是在特定的数据集上得出来的.
The summary of experiments datasets for SATD empirical studies
进行SATD实证研究使用的数据集汇总
文献 | 项目个数 | 标签收集方式 | 调研内容 | 复用文献列表 | ||||
种类 | 分布 | 根因 | 移除 | 影响 | ||||
[ |
4 | 手工标注 | - | [ |
||||
[ |
5 | 手工标注 | - | - | - | - | ||
[ |
159 | Pattern识别[ |
- | - | - | |||
[ |
5 | Pattern识别[ |
- | - | - | - | - | |
[ |
1 | 手工标注 | - | - | - | - | - | |
[ |
4 | Pattern识别[ |
- | - | - | - | - | |
[ |
5 | NLP识别[ |
- | - | - | [ |
||
[ |
5 | NLP识别[ |
- | - | - | - | [ |
|
[ |
1 | Pattern识别[ |
- | - | - | - | - | |
[ |
5 | 手动标注 | - | - | - | - | ||
[ |
2 | 手动标注 | - | - | - | - | ||
[ |
7 | 手动标注 | - | - | - | - |
(1) 多样性. 在不同的实证研究中, 研究者使用SATD数据集来调研不同的特性, 包括调研SATD的分布及其分类[
(2) 差异性. 对同一类特性进行调研时, 研究者通常会从不同的项目中重新收集数据. 例如, 有六篇文献的研究者使用了不同的数据集来研究SATD种类. 在不同数据集上进行调研可以使得结论更加全面. 与此同时, 不同研究者在收集数据时会带来个人偏好. 因此对同一特性的调研在不同的文献中表现会有差异[
(3) 唯一性. 多数研究的数据集仅仅出现在一篇研究文献中, 仅有部分数据集(如Potdar等人[
(4) 不可靠性. 某些调研[
本节介绍了近年来对SATD特性方面的研究, 主要从 SATD种类、分布、根因、移除和SATD对软件质量的影响5个方面进行介绍. 下面总结主要的发现.
(1) 种类. 现有研究根据注释的不同语意描述划分出10种类型的SATD, 分别为代码债、缺陷债、设计债、文档债、需求债、测试债、兼容债、算法债、架构债和构建债.
(2) 分布. 在不同类型的债务中占比较多的是设计债、代码债和需求债这3种类型[
(3) 根因. 很多SATD是由有经验的开发者引入项目中的, 并且会在项目中长时间存在[
(4) 移除. 项目中有部分(如57%[
(5) 影响. SATD会增加软件的后期维护成本, 包括增大变更难度[
(6) 研究者所用的数据集大多不相同, 在此基础上进行实证研究可以提高调研结果的泛化性, 但同时也会引入一些矛盾的结论[
对SATD进行识别的研究是近年来(特别是2017年之后)的研究重点. 从本质上讲, 识别注释中的SATD是对文本进行二分类的过程[
有监督模型是一类重要的SATD识别模型, Maldonado等人[
The summary of supervised self-admitted technical debt identification models
识别SATD有监督模型汇总
年份 | 文献 | 重要的模型组件 | 识别债务类型 | 分类器类别 |
2017 | [ |
NLP处理; Stanford分类器 | 设计债需求债 | 二分类 |
[ |
方法级度量和静态分析工具 | 设计债 | 二分类 | |
2018 | [ |
文本挖掘; 特征选择IG; 投票机制 | 不区分类型 | 二分类 |
[ |
N-gram IDF; 自动机器学习 | 设计债需求债 | 二分类 | |
[ |
词嵌入; 特征选择 | 不区分类型 | 二分类 | |
2019 | [ |
卷积神经网络 | 不区分类型 | 二分类 |
[ |
词嵌入; 特征选择 | 不区分类型 | 二分类 | |
[ |
N-gram IDF; 下采样; 随机森林分类器 | 设计债需求债 | 三分类 | |
[ |
On hold类型的SATD;NLP分类器 | 不区分类型 | 二分类 | |
2020 | [ |
LSTM神经网络模型; 词嵌入 | 设计债需求债 | 二分类 |
[ |
分治策略; 人工辅助 | 不区分类型 | 二分类 |
作为训练和测试数据的代码注释是用自然语言书写的. 自然语言在进行书写时用法十分灵活并且形式各异, 这种差异性会给模型构建带来挑战. 为了缓解这一问题, 很多研究[
(1) 符号化(tokenization). 这一步去除了注释中包含的无用符号, 包括标点符号(如“:”)和其他非字母组成的元素(如 “//”), 然后将注释文本切分为独立的单词, 同时将所有单词转换为小写形式.
(2) 移除停用词(stop-word removal). 停用词是指一些没有意义或者区分度的单词(例如“I”“the”“to”等), 在这一步中这些停用词将会从备选单词中移除以降低其对预测模型的影响. 要注意, 在不同的模型中采用的停用词表不完全相同, 这取决于具体的模型实现.
(3) 提取词干(stemming). 最后一步将所有单词的变体转换为其原始形式(例如将“processing”转换为“process”), 因为不同变体所具有的词意基本是一致的.
An example of preprocessing of code comments
对代码注释的预处理的样例
2017年, Maldonado等人[
2018年, Flisar等人[
由于设计债和需求债在所有类型债务中的占比较多[
2019年, Maipradit等人[
2017年, Zampetti等人[
2018年, Huang等人[
2020年, Yu等人[
2019年, Santos等人[
同年, Ren等人[
相比于有监督模型, 无监督模型的构建和使用十分方便. 这类方法的最新研究展示出与有监督模型相比肩的性能. 无监督的模型主要是通过总结不同的技术债模式(pattern)来识别SATD的存在[
The summary of unsupervised self-admitted technical debt identification models
识别SATD的无监督模型汇总
年份 | 文献 | 说明 | 模式样例 |
2014 | [ |
人工总结模式 | todo, this is wrong |
2015 | [ |
上下文语境词汇表, 组合不同词类和Tag | |
2018 | [ |
人工总结模式 | TODO: not yet supported TODO: not documented |
2019 | [ |
任务标签模糊匹配 | todo, fixme, hack, xxx |
2020 | [ |
改良的上下文语境词汇表, 考虑到词汇的
|
Todo: temporary Note: This is temporary
|
2014 年, Potdar等人[
2015年, Farias等人[
2018年, Passos等人[
2019年, Guo等人[
本小节从评估指标、实验数据集和性能比较3个部分来介绍学术界对SATD识别模型的评估方法和结果.
为了评估一个SATD识别模型的有效性, 研究者[
从二分类的角度来看, 对注释进行识别的分类结果总共可以划分为以下4种可能情况.
● 对于一个被识别为包含SATD的注释, 它的确包含SATD, 这种结果属于TP (true positive);
● 对于一个被识别为包含SATD的注释, 它并不包含SATD, 这种结果属于FP (false positive);
● 对于一个被识别为没有SATD的注释, 它的确包含SATD, 这种结果属于FN (false negative);
● 对于一个被识别为没有SATD的注释, 它并不包含SATD, 这种结果属于TN (true negative).
现有的二分类评价指标首先基于上述4种情况的混淆矩阵(见
Confusion matrix
混淆矩阵
预测为SATD | 预测为non-SATD | |
真实为SATD | TP | FN |
真实为non-SATD | FP | TN |
(1) Precision (精度). 在预测为包含SATD的注释实例中, 有多少比例的注释真正包含SATD.
(2) Recall (召回率). 在所有真正包含SATD的注释实例中, 有多少比例的注释被模型识别出来.
(3)
(4) Accuracy (准确率)在所有分类结果中, 正确分类的注释实例(包括正确分为SATD的实例和正确分为non-SATD的实例)占所有注释实例的比重.
(5) MCC (Matthews correlation coefficient, 马修斯相关系数). 表示的是真实类别和预测类别的二元分类之间的相关系数.
在上述指标中, Precision、Recall、
为了准确评估SATD识别模型的效果, 需要收集可靠的数据集进行验证. 综合已有研究, 评估数据集的收集主要包含以下3个步骤(如
The process of collecting comments data
注释数据集收集过程
(1) 解析代码
这一步的目的是从项目中获取注释实例, 研究者通常使用一些自动工具来解析项目代码并抽取其中的注释部分. 例如, Maldonado等人[
(2) 过滤注释
直接从项目中提取的注释文本是由噪声的数据, 其中包含许多明显的特征表明它们不是SATD的注释. 使用这些数据进行训练和测试不能够准确地对模型进行评估[
● 许可注释(license comments). 这类注释通常被添加在类的声明之前并且描述了代码的许可信息. 通常这类注释中是不包含SATD的. 要注意的是, 如果这类注释中包含任务标签(如“TODO”、“FIXME”或者“XXX”), 那么则不过滤这些注释, 因为这些标签通常伴随着SATD出现;
● 自动生成的注释(automatically generated comments). 这类注释是由开发环境自动生成的注释, 它们没有描述任何有实际意义的内容因此不能够指明SATD. 例如,“Auto-generated constructor stub”;
● Java文档注释(Javadoc comments). 这类注释的作用是解释Java代码中的实体的定义以及功能说明. 其中通常不会包含SATD除非其中包含任务标签;
● 被注释的代码段(commented source code). 这类注释指的是代码中有些暂时不用的代码被注释掉的内容. 通常从直观上来说我们无法获得与SATD有关的文字描述, 因此需要过滤掉;
● 长注释(long comments). 项目中某些长注释是由紧邻的多个单行注释组成的. 这些单行注释在形式上是分离的, 但是在内容上描述的是一个整体的事件. 对这类注释需要将这些紧邻的单行注释组合成一个完整的注释实例而不是过滤.
(3) 手工分类
这一步为过滤后的注释标记其类别(SATD注释或者non-SATD). 标记过程是人工完成的. 为了降低人为因素带来的偏好, 通常会由若干名研究者同时进行标注并且对有歧义的实例进行讨论后确定其类别或者先由一人进行标记并让另一人进行抽样标记之后计算Cohen’s kappa系数[
使用上述中的过程可以为模型验证提供比较可靠的数据集. Maldonado等人[
The summary of experiments datasets for self-admitted technical debt identification models
用于评估SATD识别方法性能的数据集[
Project | Release | #Comments | After filtering | #SATD | SATD (%) | Cont. | #classes | KLOC |
Ant | 1.7.0 | 21 587 | 3 052 | 102 | 0.47 | 74 | 1 475 | 115 |
ArgoUML | 0.34 | 67 716 | 5 426 | 969 | 1.43 | 87 | 2 609 | 926 |
Columba | 1.4 | 33 895 | 4 090 | 128 | 0.38 | 10 | 1 711 | 155 |
EMF | 2.4.1 | 25 229 | 2 585 | 74 | 0.29 | 30 | 1 458 | 228 |
Hibernate | 3.3.2 | 11 630 | 2 492 | 377 | 3.24 | 314 | 1 356 | 703 |
JEdit | 4.2 | 16 991 | 4 644 | 195 | 1.15 | 57 | 800 | 310 |
JFreeChart | 1.0.19 | 23 474 | 2 494 | 101 | 0.43 | 19 | 1 065 | 317 |
JMeter | 2.1.0 | 20 084 | 4 148 | 282 | 1.40 | 41 | 1 181 | 354 |
JRuby | 1.4.0 | 11 149 | 3 652 | 383 | 3.44 | 374 | 1 486 | 841 |
SQuirrel | 3.0.3 | 27 474 | 4 473 | 201 | 0.73 | 40 | 3 108 | 708 |
Total | - | 259 229 | 37 056 | 2,812 | 1.08 | 1 046 | 16 249 | 4 657 |
本小节汇总了现有的部分SATD识别模型的在上述数据集[
Performance comparison among SATD identification models when identifying all types of debts
SATD识别模型在识别所有债务时的性能比较
由于设计债和需求债在所有债务中所占比重较大并且对软件系统有着重要影响, 现有的若干研究设计模型针对这两类SATD进行识别.
本节主要介绍了有监督模型和无监督模型两方面详细介绍了SATD识别模型近年的研究进展. 下面简述主要发现.
(1) 有监督模型的比重较大, 这类模型会应用各种建模技术, 包括自然语言处理、传统机器学习和深度学习等. 这类模型的分类效果相对来说比较好, 存在的不足是这类模型比较复杂会对实用性产生负面影响.
(2) 无监督模型主要的思想是通过模式(即关键词)匹配来识别注释中的SATD. 这类模型比较简单直观, 实际操作更加方便, 不足之处是部分模型的分类效果很差并且可能需要消耗人力成本来总结模式.
(3) 许多识别模型属于二分类模型, 它们不关心SATD所属于的种类(如设计债或者需求债), 仅仅关注待测注释实例是否是SATD, 这些模型在一定程度上简化了任务, 但不能对SATD的移除提供启示.
(4) 目前对模型进行的验证的数据集比较单一. 大多数研究在Maldonado等人[
学术界对技术债的研究手段是多种多样的, 不仅仅可以使用代码注释对其进行研究和识别. 本节中简要介绍使用其他手段研究SATD的相关工作.
Performance comparison among SATD identification models when identifying design and requirement debts
SATD识别模型在识别设计债和需求债时的性能比较
2019年, Yan等人[
2020年, Xavier等人[
同年, Li等人[
从现有文献来看, 当前对SATD的研究还存在着若干需要解决的挑战. 本节分别介绍该领域的实证调研和识别模型两类研究中所面临的挑战.
(1) 来自实证研究数据集的挑战. 数据集中的挑战主要来自两个方面: 1) 数据集标签的准确性存在问题. 有些实证研究[
(2) 来自分析方法差异性的挑战. 不同研究的分析方法不完全一致, 其中的差异性会给不同研究结论一致性带来挑战. 例如, 在对SATD的类型进行分析时, Maldonado等人[
(1) 来自模型构建方法的挑战. 在构建识别模型时存在一些挑战会影响模型的性能. 1)部分识别模型在构建时[
(2) 来自模型有效性的挑战. 在目前所提出的各种模型中, 一方面, 有监督模型通常能够达到比较好的分类性能(其中CNN模型[
(3) 来自模型实用性的挑战. 当前的有监督和无监督模型中都存在实用性的挑战, 这些挑战增加了开发者的使用成本因此实用性较低. 有监督模型的挑战来自于其复杂的模型设计, 其中包含了各种结构和参数的调节, 如NLP模型[
(4) 来自模型验证数据集的挑战. 数据集的数量和可靠性存在问题, 目前研究者大多使用Maldonado等人[
针对SATD研究中存在的挑战以及现有研究中的结论, 我们从总结了以下几方面的研究方向可能需要得到研究者的重点关注.
(1) 提供明确统一的SATD种类定义. 正如3.1节中所说, 目前对SATD进行种类划分的依据是根据注释的内容进行人工分类, 具有较强的主观性和分类偏好. 因此在今后的研究中, 推荐研究者能够提出明确无歧义的SATD种类划分定义. 这将具有以下两点重要的意义. 1) 首先, 这将极大地有利于研究者根据SATD种类定义来编写规则脚本进行自动化地SATD种类划分而非耗时耗力的人工划分. 2) 其次, 这将有助于指导开发者在添加SATD注释时遵循明确的定义来规范注释的书写, 从而为SATD的后续管理提供便利.
(2) 按照种类更细化地研究SATD. 目前常见的SATD可以根据其含义划分为10个不同的种类(如设计债、需求债等). 描述不同种类的SATD所用的语言和词汇有较大的差异性[
(3) 研究SATD移除方法的自动化推荐模型. 对SATD进行研究的最终目标是要移除项目中存在的SATD来保障软件质量和健壮性[
(4) SATD管理工具的设计和开发. SATD普遍长时间存在于项目中[
(5) 研究问题追踪系统中的SATD. 根据Xavier等人[
(6) 构建规范的SATD数据集. 现有的数据集存在一些问题(见第6.1节). 很多研究使用的数据现已无法在网上获取, 数据集中的部分标签信息有误[
(7) 支持其他软件质量保障相关的研究. SATD是存在于软件代码中的有用实体, 其中包含部分与软件缺陷相关的信息(如, 位置、优先级等). 研究者合理利用SATD提供的信息可以支持其他软件质量保障相关(如缺陷定位[
当自承认技术债(SATD)的概念被提出后, 立即受到大量研究者的重点关注并且在该领域发表了数十篇研究成果. 本文根据不同文献的侧重点围绕对SATD特性的调研和对SATD的识别两个方面对当前的研究工作进行了梳理和总结. 主要工作总结如下: (1) 本文从SATD的种类、分布、根因、移除和影响5个维度对SATD特性的调研进行归类和阐述, 并且对实证研究中的数据集信息进行了分析; (2) 本文首先根据不同的模型设计原理介绍当前的SATD识别模型; 然后从评价指标、实验数据集和性能比较3方面总结该领域的现状; (3) 本文从数据集、有效性和实用性等角度总结了当前对SATD的研究面临的挑战并针对性地从7个方面指出了未来需要重点专注的研究方向.
致 谢 感谢编辑以及两位匿名审稿专家提出的宝贵意见, 提高了这篇综述的质量!
10.1109/MTD.2015.7332619]]]>
da Silva Maldonado E, Shihab E, Tsantalis N. Using natural language processing to automatically detect self-admitted technical debt. IEEE Transactions on Software Engineering, 2017, 43(11): 1044–1062. [doi: 10.1109/TSE.2017.2654244]
Lim E, Taksande N, Seaman C. A balancing act: What software practitioners have to say about technical debt. IEEE Software, 2012, 29(6): 22–27. [doi: 10.1109/MS.2012.130]
10.1109/ICSME.2014.31]]]>
10.1109/SANER.2016.72]]]>
Huang Q, Shihab E, Xia X, Lo D, Li SP. Identifying self-admitted technical debt in open source projects using text mining. Empirical Software Engineering, 2018, 23(1): 418–451. [doi: 10.1007/s10664-017-9522-4]
10.1145/3379597.3387459]]]>
Cunningham W. The WyCash portfolio management system. ACM SIGPLAN OOPS Messenger, 1992, 4(2): 29–30. [doi: 10.1145/157710.157715]
10.1145/2901739.2901742]]]>
Kruchten P, Nord RL, Ozkaya I, Falessi D. Technical debt: Towards a crisper definition report on the 4th international workshop on managing technical debt. ACM SIGSOFT Software Engineering Notes, 2013, 38(5): 51–54. [doi: 10.1145/2507288.2507326]
Seaman C, Nord RL, Kruchten P, Ozkaya I. Technical debt: Beyond definition to understanding report on the sixth international workshop on managing technical debt. ACM SIGSOFT Software Engineering Notes, 2015, 40(2): 32–34.[doi: 10.1145/2735399.2735419]
Ozkaya I, Kruchten P, Nord RL, Brown N. Managing technical debt in software development: Report on the 2nd international workshop on managing technical debt, held at ICSE 2011. ACM SIGSOFT Software Engineering Notes, 2011, 36(5): 33–35. [doi: 10.1145/2020976.2020979]
Kruchten P, Nord RL, Ozkaya I, Visser J. Technical debt in software development: From metaphor to theory report on the third international workshop on managing technical debt. ACM SIGSOFT Software Engineering Notes, 2012, 37(5): 36–38. [doi: 10.1145/2347696.2347698]
Falessi D, Kruchten P, Nord RL, Ozkaya I. Technical debt at the crossroads of research and practice: Report on the fifth international workshop on managing technical debt. ACM SIGSOFT Software Engineering Notes, 2014, 39(2): 31–33. [doi: 10.1145/2579281.2579311]
Avgeriou P, Ernst NA, Nord RL, Kruchten P. Technical debt: Broadening perspectives report on the seventh workshop on managing technical debt (MTD 2015). ACM SIGSOFT Software Engineering Notes, 2016, 41(2): 38–41. [doi: 10.1145/2894784.2894800]
Izurieta C, Ozkaya I, Seaman C, Snipes W. Technical debt: A research roadmap report on the eighth workshop on managing technical debt (MTD 2016). ACM SIGSOFT Software Engineering Notes, 2017, 42(1): 28–31. [doi: 10.1145/3041765.3041774]
Fontana FA, Chatzigeorgiou A, Trumler W, Izurieta C, Avgeriou P, Nord RL. Technical debt in agile development: Report on the ninth workshop on managing technical debt (MTD 2017). ACM SIGSOFT Software Engineering Notes, 2017, 42(3): 18–21. [doi: 10.1145/3127360.3127372]
10.1109/MTD.2015.7332621]]]>
10.1109/ACIT-CSII-BCD.2016.040]]]>
Sierra G, Shihab E, Kamei Y. A survey of self-admitted technical debt. Journal of Systems and Software, 2019, 152: 70–82. [doi: 10.1016/j.jss.2019.02.056]
刘亚珺, 李兵, 李增扬, 梁鹏, 吴闽泉. 软件集成开发环境的技术债务管理研究. 计算机科学, 2017, 44(11): 15−21, 40. [doi: 10.11896/j.issn.1002-137X.2017.11.003]
Liu YJ, Li B, Li ZY, Liang P, Wu MQ. Study on technical debt management of integrated development environment. Computer Science, 2017, 44(11): 15−21, 40 (in Chinese with English abstract). [doi: 10.11896/j.issn.1002-137X.2017.11.003]
张云洁, 张璇, 丁浩, 王旭. 需求变更技术债务研究. 计算机科学, 2018, 45(9): 89−93. [doi: 10.11896/j.issn.1002-137X.2018.09.013]
Zhang YJ, Zhang X, Ding H, Wang X. Study on technical debt caused by requirement change. Computer Science, 2018, 45(9): 89–93 (in Chinese with English abstract). [doi: 10.11896/j.issn.1002-137X.2018.09.013]
Li ZY, Avgeriou P, Liang P. A systematic mapping study on technical debt and its management. Journal of Systems and Software, 2015, 101: 193–220. [doi: 10.1016/j.jss.2014.12.027]
Rios N, de Mendonça Neto MG, Spínola RO. A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners. Information and Software Technology, 2018, 102: 117–145.[doi: 10.1016/j.infsof.2018.05.010]
10.1145/3341105.3373912]]]>
10.1145/1985362.1985366]]]>
10.1109/ICSME.2017.44]]]>
10.1109/MTD.2014.9]]]>
10.1109/MTD.2012.6225995]]]>
10.1145/2460999.2461005]]]>
10.1145/3131151.3131164]]]>
10.1109/ICSE.2019.00123]]]>
10.1145/3197231.3198444]]]>
Aversano L, Iammarino M, Carapella M, Del Vecchio A, Nardi L. On the relationship between self-admitted technical debt removals and technical debt measures. Algorithms, 2020, 13(7): 168. [doi: 10.3390/a13070168]
Ren XX, Xing ZC, Xia X, Lo D, Wang XY, Grundy J. Neural network-based detection of self-admitted technical debt: From performance to explainability. ACM Transactions on Software Engineering and Methodology, 2019, 28(3): 15. [doi: 10.1145/3324916]
Mensah S, Keung J, Svajlenko J, Bennin KE, Mi Q. On the value of a prioritization scheme for resolving self-admitted technical debt. Journal of Systems and Software, 2018, 135: 37–54. [doi: 10.1016/j.jss.2017.09.026]
10.1145/3196398.3196423]]]>
10.1109/ICSME.2016.72]]]>
10.1109/ICPC.2017.38]]]>
de Freitas Farias MA, de Mendonça Neto MG, Kalinowski M, Spínola RO. Identifying self-admitted technical debt through code comment analysis with a contextualized vocabulary. Information and Software Technology, 2020, 121: 106270. [doi: 10.1016/j.infsof.2020.106270]
10.1109/SEAA51224.2020.00083]]]>
10.1145/3377815.3381377]]]>
10.1109/ICSME.2017.8]]]>
Maipradit R, Treude C, Hata H, Matsumoto K. Wait for it: Identifying “On-Hold” self-admitted technical debt. Empirical Software Engineering, 2020, 25(5): 3770–3798. [doi: 10.1007/s10664-020-09854-3]
10.1109/ICSME.2019.00029]]]>
10.1109/SANER48275.2020.9054868]]]>
10.1109/SANER.2019.8667999]]]>
10.1145/2884781.2884822]]]>
10.1109/CSMR.2008.4493342]]]>
10.1109/SCAM.2011.19]]]>
10.1145/3183440.3183478]]]>
10.1109/APSEC48747.2019.00050]]]>
Yan M, Xia X, Shihab E, Lo D, Yin JW, Yang XH. Automating change-level self-admitted technical debt determination. IEEE Transactions on Software Engineering, 2019, 45(12): 1211–1229. [doi: 10.1109/TSE.2018.2831232]
10.1145/3275245.3275248]]]>
10.1145/3330204.3330227]]]>
10.1109/IWESEP.2018.00010]]]>
10.1007/978-3-319-62386-3_14]]]>
10.1007/978-3-030-43020-7_93]]]>
10.1007/978-3-319-51472-7_2]]]>
10.1109/SEAA.2018.00045]]]>
Flisar J, Podgorelec V. Identification of self-admitted technical debt using enhanced feature selection based on word embedding. IEEE Access, 2019, 7: 106475–106494. [doi: 10.1109/ACCESS.2019.2933318]
10.1109/QRS.2015.49]]]>
https://github.com/iwnsew/ngweight]]>
10.1007/978-3-030-05318-5_6]]]>
Buse RPL, Weimer WR. Learning a metric for code readability. IEEE Transactions on Software Engineering, 2010, 36(4): 546–558. [doi: 10.1109/TSE.2009.70]
Sebastiani F. Machine learning in automated text categorization. ACM Computing Surveys, 2002, 34(1): 1–47. [doi: 10.1145/505282.505283]
10.5220/0009796001570165]]]>
Cohen J. A coefficient of agreement for nominal scales. Educational and Psychological Measurement, 1960, 20(1): 37–46. [doi: 10.1177/001316446002000104]
versus class overlapping: An analysis of a learning system behavior. In: Proc. of the 3rd Mexican Int’l Conf. on Artificial Intelligence. Mexico City: Springer, 2004. 312–321. [doi: 10.1007/978-3-540-24694-7_32]]]>
Batista GEAPA, Prati RC, Monard MC. A study of the behavior of several methods for balancing machine learning training data. ACM SIGKDD Explorations Newsletter, 2004, 6(1): 20–29. [doi: 10.1145/1007730.1007735]
http://www.jos.org.cn/1000-9825/6087.htm]]>
http://www.jos.org.cn/1000-9825/6087.htm]]>
http://www.jos.org.cn/1000-9825/4923.htm [doi: 10.13328/j.cnki.jos.004923]]]>
http://www.jos.org.cn/1000-9825/4923.htm [doi: 10.13328/j.cnki.jos.004923]]]>