Leonardo da Silva Sousa

Does refactoring improve software structural quality? A longitudinal study of 25 projects

Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. Refactoring is widely practiced by developers, and considerable development effort has been invested in refactoring tooling support. There is an explicit assumption that software refactoring improves the structural quality of a program by reducing its density of code smells. However, little has been reported about whether and to what extent developers successfully remove code smells through refactoring. This paper reports a first longitudinal study intended to address this gap. We analyze how often the commonly-used refactoring types affect the density of 5 types of code smells along the version histories of 25 projects. Our findings are based on the analysis of 2,635 refactorings distributed in 11 different types. Surprisingly, 2,506 refactorings (95.1%) did not reduce or introduce code smells. Thus, these findings suggest that refactorings lead to smell reduction less often than what has been reported. According to our data, only 2.24% of refactoring changes removed code smells and 2.66% introduced new ones. Moreover, several smells induced by refactoring tended to live long, i.e., 146 days on average. These smells were only eventually removed when smelly elements started to exhibit poor structural quality and, as a consequence, started to be more costly to get rid of.

Tracking Dengue Epidemics Using Twitter Content Classification and Topic Modelling

Detecting and preventing outbreaks of mosquito-borne diseases such as Dengue and Zika in Brasil and other tropical regions has long been a priority for governments in affected areas. Streaming social media content, such as Twitter, is increasingly being used for health vigilance applications such as flu detection. However, previous work has not addressed the complexity of drastic seasonal changes on Twitter content across multiple epidemic outbreaks. In order to address this gap, this paper contrasts two complementary approaches to detecting Twitter content that is relevant for Dengue outbreak detection, namely supervised classification and unsupervised clustering using topic modelling. Each approach has benefits and shortcomings. Our classifier achieves a prediction accuracy of about 80i¾?% based on a small training set of about 1,000 instances, but the need for manual annotation makes it hard to track seasonal changes in the nature of the epidemics, such as the emergence of new types of virus in certain geographical locations. In contrast, LDA-based topic modelling scales well, generating cohesive and well-separated clusters from larger samples. While clusters can be easily re-generated following changes in epidemics, however, this approach makes it hard to clearly segregate relevant tweets into well-defined clusters.

No Code Anomaly is an Island

A software product line (SPL) is a set of systems that share common and varying features. To provide large-scale reuse, the components of a SPL should be easy to maintain. Therefore, developers have to identify anomalous code structures – i.e., code anomalies – that are detrimental to the SPL maintainability. Otherwise, SPL changes can eventually propagate to seemly-unrelated features and affect various SPL products. Previous work often assume that each code anomaly alone suffices to characterize SPL maintenance problems, though each single anomaly may represent only a partial, insignificant, or even inexistent view of the problem. As a result, previous studies have difficulties in characterizing anomalous structures that indicate SPL maintenance problems. In this paper, we study the surrounding context of each anomaly and observe that certain anomalies may be interconnected, thereby forming so-called anomaly agglomerations. We characterize three types of agglomerations in SPL: feature, feature hierarchy, and component agglomeration. Two or more anomalies form an agglomeration when they affect the same SPL structural element, i.e. a feature, a feature hierarchy, or a component. We then investigate to what extent non-agglomerated and agglomerated anomalies represent sources of a specific SPL maintenance problem: instability. We analyze various releases of four feature-oriented SPLs. Our findings suggest that a specific type of agglomeration indicates up to 89% of sources of instability, unlike non-agglomerated anomalies.

Collaborative identification of code smells: a multi-case study

Code smells are anomalous program structures that may indicate software maintainability problems. God Classes and Feature Envies are examples of code smells that frequently become the target of software refactoring. However, smell identification might be harder than expected due to the subjectivity involved in the recognition of the apparently simple structure of each smell. Moreover, smell identification might require the knowledge of multiple program elements, which are better understood by different developers. Thus, the use of collaboration among developers may have the potential to improve effectiveness on smell identification. However, current knowledge, especially empirically developed and evaluated in the industry, is quite scarce. This paper reports an industrial case study aimed at observing how 13 developers individually and collaboratively performed smell identification in five software projects from two software development organizations. Our results suggest that collaboration contributes to improving effectiveness on the identification of a wide range of code smells. We also analyzed the factors contributing to such effectiveness improvement.

How Do Software Developers Identify Design Problems?: A Qualitative Analysis

When a software design decision has a negative impact on one or more quality attributes, we call it a design problem. For example, the Fat Interface problem indicates that an interface exposes non-cohesive services Thus, clients and implementations of this interface may have to handle with services that they are not interested. A design problem such as this hampers the extensibility and maintainability of a software system. As illustrated by the example, a single design problem often affects several elements in the program. Despite its harmfulness, it is difficult to identify a design problem in a system. It is even more challenging to identify design problems when the source code is the only available artifact. In particular, no study has observed what strategy(ies) developers use in practice to identify design problems when the design documentation is unavailable. In order to address this gap, we conducted a qualitative analysis on how developers identify design problems in two different scenarios: when they are either familiar (Scenario 1) or unfamiliar (Scenario 2) with the analyzed systems. Developers familiar with the systems applied a diverse set of strategies during the identification of each design problem. Some strategies were frequently used to locate code elements for analysis, and other strategies were frequently used to confirm design problems in these elements. Developers unfamiliar with the systems relied only on the use of code smells along the task. Despite some differences among the subjects from both scenarios, we noticed that developers often search for multiple indicators during the identification of each design problem.

Revealing design problems in stinky code: a mixed-method study

Developers often have to locate design problems in the source code. Several types of design problem may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e. program locations - e.g., a class or a hierarchy - affected by multiple smells. The stinkier a program location is, more likely it contains a design problem. However, there is limited understanding if developers can effectively identify a design problem in stinkier code. Developers may struggle to make a meaning out of inter-related smells affecting the same program location. To address this matter, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code - i.e., a program location affected by multiple smells. We performed an experiment and an interview with 11 professionals. Surprisingly, our analysis revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. On the other hand, 63.63% of the developers reported much lesser false positives. Developers reported that analyses of stinky code scattered in class hierarchies or packages is often difficult, time consuming, and requires proper visualization support. Moreover, it remains time-consuming to discard stinky program locations that do not represent design problems.

Identifying design problems in the source code: a grounded theory

The prevalence of design problems may cause re-engineering or even discontinuation of the system. Due to missing, informal or outdated design documentation, developers often have to rely on the source code to identify design problems. Therefore, developers have to analyze different symptoms that manifest in several code elements, which may quickly turn into a complex task. Although researchers have been investigating techniques to help developers in identifying design problems, there is little knowledge on how developers actually proceed to identify design problems. In order to tackle this problem, we conducted a multi-trial industrial experiment with professionals from 5 software companies to build a grounded theory. The resulting theory offers explanations on how developers identify design problems in practice. For instance, it reveals the characteristics of symptoms that developers consider helpful. Moreover, developers often combine different types of symptoms to identify a single design problem. This knowledge serves as a basis to further understand the phenomena and advance towards more effective identification techniques.

Towards effective teams for the identification of code smells

Code smells are symptoms of poor design and implementation choices. Several techniques for the automated detection of code smells have been proposed, but their effectiveness is limited due to the inherent subjectivity of the task. Accepting false warnings generated by a tool may lead to unnecessary maintenance effort. Moreover, bypassing undetected smells may contribute to the software degradation. Thus, developers need to perform a subsequent manual identification of code smells to confirm their occurrences as well as address both false and missing warnings. However, performing ad hoc manual identification of smells does not assure more effective results. Indeed, different context factors may influence on the conclusion about the incidence of a code smell. Based on evidence collected from previous work, this paper presents and discusses a set of context factors that may influence the effectiveness of smell identification tasks. These factors are addressed to human aspects, such as the interaction among individuals and their professional roles. Based on such factors, we present an initial set of practical suggestions for composing more effective teams to the identification of code smells.

Spotting design problems with smell agglomerations

Design problems are structures that indicate violations of key design principles or rules. The main difficulty to identify them in the source code is due to the fact they are scattered through several code elements. Thus, code smells - microstructures in the program - have been used to reveal surface indications of a design problem. However, individually, each code smell represents only a partial embodiment of a design problem. Since design problem is scattered through several program elements, we are investigating a strategy to select a group of code smells that is likely to help developers to find design problems. We call \textit{agglomeration} this group of code smells. Our main goal is to summarize smell agglomerations that better indicate the occurrence of design problems. Our strategy to derive agglomerations is based on capturing semantic relations among closely-related code smells. We will assess to what extent code smell agglomerations help developers to locate and prioritize design problems.

On the identification of design problems in stinky code: experiences and tool support

BackgroundDevelopers often have to locate design problems in the source code. Several types of design problems may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e., program locations—e.g., a class or a hierarchy—affected by multiple smells. There is evidence that the stinkier a program location is, the more likely it contains a design problem. However, there is no empirical evidence on whether developers can effectively identify a design problem in stinkier code. Developers may struggle to make an analysis of inter-related smells affecting the same program location. Besides that, the analysis of stinkier code may require proper tool support due to its analysis complexity. However, there is little knowledge on what are the requirements for a tool that helps developers in revealing stinkier program locations. As a result, developers may not be able to identify design problems due to tool issues.MethodTo address this matter, we aimed at achieving three goals. In the first case, we proposed Organic—a tool supporting the analysis of stinky code. In the second case, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code—i.e., a program location affected by multiple smells. We conducted a study with 11 software professionals. Finally, in the third case, we aimed at understanding if Organic could be used by developers to identify design problems. To achieve this goal, we used a method from the Semiotic Engineering theory. This method enabled us to evaluate what are the tool issues that may hinder the identification of design problems in stinky code.ResultOur study revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. Moreover, 63.63% of the developers reported much lesser false positives when using the first approach as compared to the latter. The second study, in its turn, showed that most developers may be unable to identify design problems in stinky code without proper tool support.ConclusionOur experiences, in particular the second study, helped us to refine the features of Organic for better supporting developers in reflecting upon stinkier code. For example, analyses of stinky code scattered in class hierarchies or packages is often difficult, time-consuming, and requires proper visualization support. Moreover, without effective support, it remains time-consuming to discard stinky program locations that do not represent design problems.