代码坏味的处理顺序

选取了10种具有代表性的代码坏味进行研究.从每种代码坏味的产生原因、症状、对软件的影响以及相应的处理这4个方面进行分析,提出了一个代码坏味处理顺序的优先级.通过问卷调查和两个实验,对代码坏味处理顺序优先级进行了初步验证.     

代码坏味对软件演化影响的实证研究

代码坏味是指程序设计中存在的不良设计模式或设计缺陷.坏味的存在,被认为会阻碍软件的演化与维护.近年来,研究人员致力于探究坏味产生的影响以及坏味与软件演化之间的关系.已有研究表明,代码坏味会随着软件的演化而不断发生变化.通常,软件的演化将涉及源文件的增加、修改与删除这3类具体操作,了解代码坏味与软件演化中源文件操作的关系,将有助于开发者更好地计划软件开发过程和重构软件代码.因此,针对13种常见的坏味,在8个Java项目共计104个版本中进行了系统的实证研究.研究发现,随着软件版本的演化,含代码坏味的文件在整个项目中的占比在不同的项目中呈现出不同的特征.另外,包含代码坏味的文件更倾向于被修改,而坏味本身与文件的添加或者删除并没有太大的关联.更进一步地,在探究的所有坏味中,有几种特定的坏味对文件的修改产生了显著的影响,且这些坏味文件间存在着明显的重叠.这些发现有助于开发人员更好地了解代码坏味,以便于更好地对软件进行维护.     

代码坏味检测及重构的现状分析

软件良好的设计质量能使维护和重用变得更加容易和方便,而如果代码中存在各种各样的坏味,那么必将导致软件整体设计质量降低。首先对坏味的定义、描述和分类进行分析,之后列举现有的坏味检测以及重构研究,对其进行分析和比较。现状分析之后指出了现存的不足之处,为新的研究指明了方向。     

基于深度学习的耦合度相关代码坏味检测方法

基于启发式和机器学习的代码坏味检测方法已被证明具有一定的局限性,且现有的检测方法大多集中在较为常见的代码坏味上。针对这些问题,提出了一种深度学习方法来检测过紧的耦合、分散的耦合和散弹式修改这三种与耦合度相关检测较为少见的代码坏味。首先,提取三种代码坏味需要的度量并对得到的数据进行处理;之后,构建卷积神经网络（CNN）与注意力（Attention）机制相结合的深度学习模型,引入的注意力机制可以对输入的度量特征进行权重的分配。从21个开源项目中提取数据集,在10个开源项目中对检测方法进行了验证,并与CNN模型进行对比。实验结果表明：过紧的耦合和分散的耦合在所提模型中取得了更好的结果,相应代码坏味的查准率分别达到了93.61%和99.76%;而散弹式修改在CNN模型中有更好的结果,相应代码坏味查准率达到了98.59%。     

基于预训练模型和多层次信息的代码坏味检测方法

目前已有的代码坏味检测方法仅依赖于代码结构信息和启发式规则, 对嵌入在不同层次代码中的语义信息关注不够, 而且现有的代码坏味检测方法准确率还有进一步提升的空间. 针对该问题, 提出一种基于预训练模型和多层次信息的代码坏味检测方法DeepSmell, 首先采用静态分析工具提取程序中的代码坏味实例和多层次代码度量信息, 并...     

基于实时重构的代码质量教育

介绍软件代码质量的重要性以及当前代码质量教育方面工作的不足,提出将代码坏味检测工具引入程序设计课程实践教学可以提高代码质量教育的观点。文章设计一个实验方案对基于传统说教和代码坏味检测工具两种方式的代码质量教育效果进行了对比研究,最后对实验结果进行分析和总结。     

代码审查自动化研究综述

随着现代软件规模的不断扩大,协作开发成为软件开发的主流趋势,代码审查成为了现代化软件开发的重要工作流程.但由于人工代码评审往往耗费审查者较大精力,且存在审查者不匹配或审查者水平有限等问题,人工代码评审的质量和效率难以保证,且审查后的代码修复也十分费时费力.因此亟需研究人员为代码审查流程进行改进,提供自动化思路.本文对代码审查自动化相关研究进行系统梳理和总结,并重点介绍4种主要方向:审查者推荐、代码变更质量评估、审查意见生成和代码自动修复.并整理了相关方向的148篇研究,对每个方向的研究进行技术分类与分析.随后,本文整理了各方向研究任务的评估方法,并整理出常用的数据集与开源工具.最后,对代码审查自动化领域面临的问题进行梳理,并对未来研究进行展望.     

重复代码的重构

重构是当下软件工程领域研究的一个重要研究课题,在软件开发和软件维护的过程中,程序员逐渐认识到其重要性。本文先从重构的定义,重构的意义和重构的时机等几个方面系统地介代码件重构的相关内容,然后列举了重构所要解决的几种常见的代码坏味。最后后结合一个具体实例展示了重复代码这一常见坏味产生的原因以及重构过程。     

一种基于深度学习的上帝类检测方法

上帝类是指某个承担了本应由多个类分别承担的多个职责的类.上帝类违背了分而治之的基本思想以及单一职责的设计原则,严重影响软件的可维护性和可理解性.但上帝类又是一种比较常见的代码坏味.因此,针对上帝类的检测与重构一直是代码重构领域的研究热点之一.为此,提出了一种基于深度神经网络的上帝类检测方法.该方法不仅利用了常见的软件度量,而且充分利用了代码中的文本信息,意图通过挖掘文本语义揭示每个类所承担的主要角色.此外,为了解决有监督深度学习所需的海量标签数据,提出了一种基于开源代码构造标签数据的方法.最后,基于开源数据集对所提出的方法进行了实验验证.实验结果表明,这些方法优于现有的上帝类检测方法,尤其是在查全率上有大幅度的提升（提高了35.58%）.     

回归测试中测试用例集扩充技术研究进展

测试用例集扩充问题(Test Suite Augmentation)是回归测试研究的一个最新研究热点.在完成代码修改影响分析后,对已有测试用例集的充分性进行评估,若不充分则设计新的测试用例,以确保对代码修改的充分测试.但到目前为止,国内外学者并未对该研究问题的已有研究成果进行系统总结和展望.首先介绍了测试用例集扩充问题的研究背景和问题描述,然后总结出研究框架并对已有研究工作进行分类和系统比较,接着对常用评测数据集和评测指标进行了分析,最后对该问题值得关注的未来研究方向进行展望.     

Android应用程序中代码异味共存现象的实证研究

相对于单一类型的代码异味,代码异味共存现象更具危害性。已有实证研究大多聚焦于分析桌面应用程序中代码异味的共存现象,缺少对Android应用程序中代码异味共存现象的研究。为了研究Android应用程序中代码异味的共存现象,并与桌面应用程序中代码异味共存现象进行比较,分别对285个Android应用程序和30个桌面应用程序进行检测,对检测出来的10种异味进行分析。首先,根据检测结果计算受到多种异味影响的类的百分比。然后,使用公式计算代码异味共存的频率,最后,使用Spearman相关系数分析代码异味共存与应用程序规模的关系。结论如下：a）在Android应用程序中受到一种以上代码异味共同干扰的类占有异味的类的总数的31.04%;b）在两个平台的应用程序中,两对代码异味brain class—brain method和god class—brain method共存的频率较高;c）一种异味、两种异味共存、三种异味共存与Android应用程序的规模具有较强的相关性。     

基于排序损失的ECC多标签代码异味检测方法

代码异味是由糟糕的代码或设计问题引起的一种软件特征,严重影响了软件系统的可靠性和可维护性.在软件系统中,一段代码元素可能同时受到多种代码异味的影响,使得软件质量明显下降.多标签分类适用该情况,将高共现的多个代码异味置于同一标签组,可以更好地考虑代码异味的相关性,但现有的多标签代码异味检测方法未考虑同一段代码元素中多种代码异味检测顺序的影响.对此,提出了一种基于排序损失的集成分类器链(ensemble of classifier chains,ECC)多标签代码异味检测方法,该方法选择随机森林作为基础分类器并采取多次迭代ECC的方式,以排序损失最小化为目标,选择一个较优的标签序列集,优化代码异味检测顺序问题,模拟其生成机理,检测一段代码元素是否同时存在长方法长参数列表、复杂类消息链或消息链过大类这3组代码异味.实验采用9个评价指标,结果表明所提出的检测方法优于现有的多标签代码异味检测方法,F1平均值达97.16%.     

To what extent can maintenance problems be predicted by code smell detection? – An empirical study

ContextCode smells are indicators of poor coding and design choices that can cause problems during software maintenance and evolution.ObjectiveThis study is aimed at a detailed investigation to which extent problems in maintenance projects can be predicted by the detection of currently known code smells.MethodA multiple case study was conducted, in which the problems faced by six developers working on four different Java systems were registered on a daily basis, for a period up to four weeks. Where applicable, the files associated to the problems were registered. Code smells were detected in the pre-maintenance version of the systems, using the tools Borland Together and InCode. In-depth examination of quantitative and qualitative data was conducted to determine if the observed problems could be explained by the detected smells.ResultsFrom the total set of problems, roughly 30% percent were related to files containing code smells. In addition, interaction effects were observed amongst code smells, and between code smells and other code characteristics, and these effects led to severe problems during maintenance. Code smell interactions were observed between collocated smells (i.e., in the same file), and between coupled smells (i.e., spread over multiple files that were coupled).ConclusionsThe role of code smells on the overall system maintainability is relatively minor, thus complementary approaches are needed to achieve more comprehensive assessments of maintainability. Moreover, to improve the explanatory power of code smells, interaction effects amongst collocated smells and coupled smells should be taken into account during analysis.     

An approach to prioritize code smells for refactoring

Code smells are a popular mechanism to find structural design problems in software systems. Consequently, several tools have emerged to support the detection of code smells. However, the number of smells returned by current tools usually exceeds the amount of problems that the developer can deal with, particularly when the effort available for performing refactorings is limited. Moreover, not all the code smells are equally relevant to the goals of the system or its health. This article presents a semi-automated approach that helps developers focus on the most critical problems of the system. We have developed a tool that suggests a ranking of code smells, based on a combination of three criteria, namely: past component modifications, important modifiability scenarios for the system, and relevance of the kind of smell. These criteria are complementary and enable our approach to assess the smells from different perspectives. Our approach has been evaluated in two case-studies, and the results show that the suggested code smells are useful to developers.     

Code smells as system-level indicators of maintainability: An empirical study

Context

Code smells are manifestations of design flaws that can degrade code maintainability. So far, no research has investigated if these indicators are useful for conducting system-level maintainability evaluations.

Aim

The research in this paper investigates the potential of code smells to reflect system-level indicators of maintainability.

Method

We evaluated four medium-sized Java systems using code smells and compared the results against previous evaluations on the same systems based on expert judgment and the Chidamber and Kemerer suite of metrics. The systems were maintained over a period of up to 4 weeks. During maintenance, effort (person-hours) and number of defects were measured to validate the different evaluation approaches.

Results

Most code smells are strongly influenced by size; consequently code smells are not good indicators for comparing the maintainability of systems differing greatly in size. Also, from the comparison of the different evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to the system's size and complexity and could adapt to different maintenance scenarios.

Conclusion

Code smell approaches show promise as indicators of the need for maintenance in a way that other purely metric-based approaches lack.     

Code smells in pull requests: An exploratory study

The quality of a pull request is the primary factor integrators consider for its acceptance or rejection. Code smells indicate sub-optimal design or implementation choices in the source code that often lead to a fault-prone outcome, threatening the quality of pull requests. This study explores code smells in 21k pull requests from 25 popular Java projects. We find that both accepted (37%) and rejected (44%) pull requests have code smells, affected mainly by god classes and long methods. Besides, we observe that smelly pull requests are more complex and challenging to understand as they have significantly large sizes, long latency times, more discussion and review comments, and are submitted by contributors with less experience. Our results show that features used in previous studies for pull request acceptance prediction could be potentially employed to predict smell in incoming pull requests. We propose a dynamic approach to predict the presence of such code smells in the newly added pull requests. We evaluate our approach on a dataset of 25 Java projects extracted from GitHub. We further conduct a benchmark study to compare the performance of eight machine learning classifiers. Results of the benchmark study show that XGBoost is the best-performing classifier for smell prediction.     

An exploratory study on cooccurrence of design patterns and bad smells using software metrics

A design pattern is a general reusable solution to commonly recurring problems in software projects. Bad smells are symptoms existing in the source code that possibly indicate the presence of a structural problem that requires code refactoring. Although design pattern and bad smells be different concepts, literature has shown that they may be related and cooccur during the evolution of a software system. This paper presents an empirical study that investigates cooccurrences of design patterns and bad smells as well as identifies the main factors that contribute to the emergence of the relationship between them. We carried out a case study with five Java systems to: (1) investigate if the use of design pattern reduces bad smell occurrence, (2) identify cooccurrences of design patterns and bad smells, and (3) identify situations that contribute for the cooccurrence emergence. As the main result, we found that the application of design pattern not necessarily avoid bad smell occurrences. The results also show that some design patterns such as composite, factory method, and singleton, are intrinsically modular and might be useful in creating high-quality systems. However, other design patterns such as adapter-command, proxy, and state-strategy, have presented high cooccurrence frequency with bad smells; therefore, they require attention in their implementation. Finally, via manual inspection in the components with cooccurrence, we found that the identified cooccurrences appeared due to poor planning and inadequate application of design patterns.     

利用主轴因子法的严重性代码异味相关性分析

代码异味的存在对源代码的可理解性和可维护性有着糟糕的负面影响.通常情况下,研究人员更多是考虑单一代码异味对源代码的影响,但有研究指出,多种代码异味的共同存在以及它们之间的交互往往比单一代码异味有着更严重的负面影响.本文针对主成分分析在布尔类型变量分析中容易产生难以解释的主成分的弊端,提出了一种基于主轴因子法及异味严重性的代码异味相关性分析方法,并在92个系统上对14种代码异味进行试验,从中提取了6个因子,在相关矩阵中新发现了{Extensive Coupling、Long Parameter List}代码异味对的存在.最后本文比较分析了具有严重性标签的代码异味数据集的优势,解释了每个因子的含义并进行分类命名.