Large Language Models (LLMs) are increasingly used through autonomous agents (e.g., Copilot, Cursor, Devin, Claude) to perform complex software development tasks. However, little is known about how these agents introduce and document technical debt through Self-Admitted Technical Debt (SATD) comments. Understanding SATD in AI-generated code is critical, as such comments explicitly reveal acknowledged limitations and deferred fixes that affect long-term maintenance. In this study, we quantitatively and qualitatively analyze 525 SATD comments authored by AI agents using the AIDev dataset. Our results show that AI-generated SATD is slightly more technically detailed than human-authored SATD, yet both often describe problems without clear guidance on resolution. Through thematic analysis, we identify 34 SATD topics grouped into 10 categories, with AI agents predominantly documenting requirement- and design-related debt. While many SATD topics overlap between AI and humans, our taxonomy reveals new debt categories and emphases specific to AI-authored SATD, particularly related to infrastructure, pipelines, dependency management, and requirement interpretation driven by developer prompts. Overall, our findings suggest that AI- and human-authored SATD share common characteristics but differ in expression and focus, highlighting the need for deeper investigation into how agentic systems communicate and manage technical debt.

Agentic AI systems powered by Large Language Models (LLMs) are increasingly used to autonomously contribute code in modern software development. While prior work has shown that such systems can accelerate development tasks, their reliability and maintenance behavior in real-world Continuous Integration (CI) workflows remain poorly understood. In this study, we analyze 11,771 pull requests (PRs) from GitHub, including 7,619 agentic and 4,152 human-authored PRs, to investigate how agentic code behaves during CI workflows. We examine (1) CI failure rates at the pull-request level, (2) responsibility for introducing and fixing CI failures, and (3) time-to-fix at the commit level using fail–fix mappings. Our results show that human-authored CI fixes exhibit a median time to fix of 71.70 minutes, whereas AI agentic-authored CI fixes resolve failures nearly four times faster, with a median of 17.23 minutes. Our results show that agent-authored fixes resolve CI failures nearly four times faster than human fixes (median 17.23 vs. 71.70 minutes). However, agents introduce most CI failures (79.15%) while performing a smaller share of fixes (60.63%), indicating that human developers remain heavily involved in failure resolution despite faster agent responses.

AI coding agents are increasingly being adopted to autonomously author pull requests (PRs). While these agents can perform a wide range of tasks, little is known about how much human intervention is required to collaborate with them and integrate AI Agents contributions in practice. In this paper, we conduct an empirical study on human intervention in agent-authored PRs (APRs) as a measure of human effort and oversight. Using the AIDev dataset, we first compare how often humans intervene in APRs vs human-authored PRs (HPRs), as well as the resulting outcomes of this intervention. We then conduct a qualitative thematic analysis of human interventions in APRs and derive a taxonomy including 4 high-level categories and 42 intervention actions. Our results show that, human interventions occur less frequently in APRs than in HPRs (52.17% vs. 83.59%), but when it occurs in APRs, it requires higher review effort, including larger code churn and longer durations. Our taxonomy results show that most human effort is spent on guidance-level interventions with 58.02%, focusing on restricting the agent’s actions and enforcing project-conventions, followed by decision-level interventions at 21.16%, direct code changes at 17.05% and operational-level intervention at 3.69%. Which indicates that, collaboration with coding agents, is shifting developer work from implementation to supervision, guidance and quality control.

Agentic AI systems are increasingly integrated into software development workflows, contributing code alongside human developers. However, some AI-authored changes are later reverted, reflecting situations where agent-generated contributions are judged unsuitable after integration. This paper presents a large-scale empirical study of reverted changes introduced by AI coding agents to better understand the causes behind their rejection. We analyze 33,580 agentic pull requests comprising 86,315 commits authored by five major AI coding agents: Claude, Copilot, Cursor, Devin, and OpenAI Codex. Our results show that 2.66% of agentic pull requests contain at least one reverting commit, with substantial variation across agents, ranging from 0.7% for OpenAI Codex to 7.6% for GitHub Copilot indicating notable differences in code generation reliability. Through a manual analysis of 500 reverting commits, we derive a taxonomy comprising eight categories and 25 themes that explain why agent-generated code is reverted. The most common causes are unintended side effects (22.33%), overengineering (22.13%), functional incorrectness (17.71%), and dependency management problems (12.47%). Overall, our findings indicate that AI coding agents struggle primarily with scope management and contextual understanding, rather than purely functional defects. This study provides actionable guidance for practitioners, informs the design of human-AI collaboration workflows, and highlights priority areas for improving agentic code generation systems.

Refactoring is a crucial practice in software maintenance that aims at improving design and coding practices while addressing design flaws. The Extract Method refactoring is particularly popular for consolidating duplicate code fragments into a single method. Various studies have explored ways to recommend Extract Method refactoring opportunities using techniques such as program slicing, program dependency graph analysis, change history analysis, structural similarity, and feature extraction. Despite their effectiveness, these approaches often disrupt the developer’s workflow, requiring them to pause their coding and assess the refactoring opportunities suggested throughout the project, without considering the specific development context. To enhance the adoption of Extract Method refactoring, our previous work proposed AntiCopyPaster 2.0 and investigated the effectiveness of detecting and extracting code clones without disrupting the developer’s workflow. To address these limitations, we develop a new approach in this article that supports the detection of Type-1 and Type-2 clones using the Program Structure Interface (PSI) and includes a custom-built Extract Method refactoring tool. We implement our approach using an IntelliJ IDEA extension plugin. Additionally, we integrated name recommendation models, including IntelliJ’s built-in recommender and Code2Vec , to enhance the quality of method names and improve developer productivity. To evaluate the accuracy and usefulness of our approach, we conducted a qualitative study involving 13 developers. The results indicate that (1) developers appreciate the approach and are satisfied with various aspects of the plugin’s functionality, (2) PSI effectively identifies clones by analyzing the structural and semantic aspects of the code, (3) IntelliJ’s naming recommender often provides default generic names, while code2vec produces descriptive and relevant names based on the code context, (4) the performance of AntiCopyPaster remains stable regardless of the file size and the number of clones present, (5) despite different detection and correction mechanisms, JDeodorant and AntiCopyPaster were able to perform method extraction, and AntiCopyPaster features just-in-time detection and correction, and (6) our results show an improvement in code quality after performing Extract Method refactoring with both refactoring tools. We envision that our AntiCopyPaster solution can streamline the Extract Method refactoring process, enhancing both developer efficiency and code quality by seamlessly integrating Type-2 clone detection and name recommendation capabilities in the development workflow.

Infrastructure-as-Code (IaC) enables practitioners to configure and manage software infrastructure through machine-readable code files. Various IaC tools facilitate code reuse and modularity via IaC modules that act as dependencies. These modules are maintained by IaC providers to introduce new features, resolve bugs, or address security vulnerabilities. However, there is a limited understanding of how practitioners update their IaC module dependencies in their software projects, including updates frequency, delays, as well as motivations behind such updates. To fill this gap, this paper aims to understand current update practices in IaC module dependencies, focusing on Terraform (TF), being currently one of the most popular IaC tools. In particular, we investigate (i) the frequency in which IaC practitioners update their module dependencies, (ii) the technical lag phenomena, which represents the time that the infrastructure configurations remain outdated relative to their upstream modules, and (iii) the motivations that drive these updates. To achieve these, we conduct an empirical study on 13,490 TF-related commits from 131 open-source projects. Our results reveal that only 1.2% of the analyzed commits involve updating module dependencies. Furthermore, we observe an increasing technical lag from 2021 until 2024, reaching ten months on average by 2024. Then, we conduct a qualitative study using thematic analysis on code changes involving TF module dependencies updates to investigate practitioners’ motivations behind such updates. We identify that TF practitioners revolve around six main motivations, with IaC Ecosystem Compatibility, Security Vulnerabilities Fixes, and IaC Code Quality Improvement being the three most prevalent motivations. Our findings advocate that TF practitioners need customized IaC tool support for safe module dependency updates while addressing compatibility concerns.

Microservices architecture is increasingly adopted in modern software projects. Microservices deployment is often managed by tools like Spring Cloud, Consul, and Docker. Although there is existing research on microservices, practical deployment challenges are still under-explored, impacting the efficiency and success of applications. In this paper, we aim to identify and understand the challenges developers encounter with microservices deployment. We analyze trends in help requests on Stack Overflow, one of the most popular Q&A platforms for developers, to identify and categorize these challenges and highlight the most popular and difficult ones. First, we examined 1,214 Stack Overflow posts related to microservices deployment using topic modelling based on the BERTopic method to extract and analyze challenge topics. To obtain a more comprehensive understanding, we also analyzed the identified topics according to their popularity and difficulty. Our results reveal that discussions related to microservices deployment vary over time from 2013 to 2023. We identified nine distinct topics related to microservices deployment challenges, including deployment strategies, data management, composition and discovery, containerization, configuration, and orchestration in Kubernetes, security management, CI/CD pipeline automation, exposure to external clients, and post-deployment monitoring. Results reveal that microservices containerization is the most popular topic that poses numerous challenges to many users, with 2,148 average views and a 3.19 average score. While composition and discovery and post deployment monitoring are the most challenging topics, with 78 % of questions on post deployment monitoring lacking accepted answers, and 28 % of questions about composition and discovery remaining unanswered. This study identifies critical areas in microservices deployment that need further investigation, particularly, difficult and popular ones.

GitHub Actions (GHA) has become among the most popular Continuous Integration (CI) platforms in open-source software (OSS) and commercial projects. Collecting such build data remains crucial for practitioners and researchers to allow build performance monitoring, optimization and improvement. However, mining GHA builds to collect build-related data and metrics remains challenging and time-consuming. This paper introduces GHAminer, an open-source tool designed to collect build-related metrics for GitHub Actions. GHAminer covers various aspects of data such as the build-related code changes and tests, the build duration and status (e.g., passed, failed, timeout, etc.), and repository metadata, which would be useful for practitioners and researchers to make data-driven decisions to enhance CI efficiency and quality. The tool has a modular architecture that supports efficient data extraction with minimal API load. Specifically, it consists of a set of modules that are related to repository information collection, build analysis, commit history analysis, and build log parsing. We evaluate the performance of GHAminer on a representative sample of 3,151 OSS projects. Results show that GHAminer is efficient in handling projects of various sizes with relatively stable performance to collect build data for larger projects. GHAminer is publicly available with a demo video at: https:lIgithub.com/stilab-ets/GHAminer

Modern Code Review (MCR) is an essential practice in software engineering, supporting early defect detection, enhancing code quality, and fostering knowledge. To manage code review tasks effectively, developers need to understand the intent behind code changes, such as a bug fix, test, refactoring, or new feature. Traditional methods for categorizing code changes in MCR rely on rule-based heuristics with predefined keywords. However, these methods lack context regarding the code changes, leading to limited generalizability, particularly when dealing with sparsely documented changes. This paper addresses these limitations by investigating the potential of Large Language Models (LLMs) for changes' intent classification. We introduce LLM Change Classifier (LLMCC), an LLM-based approach that classifies code changes based on their underlying intent. We evaluate the effectiveness of LLMCC by conducting an empirical study on three open-source projects: Android, OpenS tack, and Qt. The performance of LLMCC was benchmarked against traditional heuristic methods, conventional machine learning algorithms (including Decision Trees and Random Forests), and state-of-the-art transformer models (including BERT and RoBERTa). Results show that LLMCC significantly enhances code change intent classification accuracy, achieving up to a 33 % improvement in F1 score over heuristic-based methods. Additionally, LLMCC outperformed both traditional machine learning and transformer models, achieving an average 77% improvement in terms of Matthew Correlation Coefficient (MCC). These findings underscore the potential of LLMCC to streamline code change intent classification.

Traffic Signal Control (TSC) is a crucial component in Intelligent Transportation Systems (ITS) for optimizing traffic flow. Deep Reinforcement Learning (DRL) techniques have emerged as leading approaches for TSC due to their promising performance. Most existing DRL-based approaches typically use discrete action spaces to predict the next action phase, without specifying the signal duration. In contrast, some studies employ continuous action spaces to determine signal phase timing within a fixed light cycle. To address the limitations of both approaches, we propose a flexible framework that predicts both the appropriate traffic light phase along with its associated duration. Our approach utilizes a Parameterized-action based deep reinforcement learning architecture to handle the combination of discrete-continuous actions. We evaluate our method using the Simulation of Urban MObility (SUMO) environment, comparing its efficiency against state-of-the-art techniques. Results demonstrate that our approach significantly outperforms traditional and learning-based methods.

Infrastructure-as-Code (IaC) automates the configuration of cloud platforms through code. As business needs evolve, IaC files often become complex, containing hundreds of lines and multiple dependencies. These configurations rely on third-party providers to provision system infrastructure. Practitioners regularly update IaC code to align with evolving cloud provider specifications (i.e., AWS, GCP, Azure) and to address security issues or defects. Although prior work highlights the risks of outdated dependencies, it remains unclear whether IaC practitioners consistently update provider dependencies in accordance with official releases. To address this gap, we conduct a mixed-method empirical study focused on the Amazon Web Services (AWS) provider, one of the most widely used providers for provisioning cloud infrastructures. We analyze 23,404 Terraform (TF) related commits from 194 open-source TF projects, focusing on: (i) technical lag, which captures how long AWS provider dependencies remain unchanged in code; (ii) the frequency of dependency updates; (iii) the code review effort involved in updating AWS provider dependencies; and (iv) the motivations behind such updates. Our findings reveal that Terraform developers frequently rely on outdated provider versions, with the technical lag increasing steadily from 2017 to early 2025, reaching a monthly average of approximately 9 months by 2025. Quantitative analysis reveals that only 1.86% of TF-related commits involve updates to AWS provider dependencies, indicating that such updates are not a priority. Moreover, related code reviews are substantial, affecting a median of 7 files across multiple directories. Through thematic analysis, we identify nine key motivations for updating the AWS provider dependencies, with the top three being: Providers Dependency Management, Terraform Compatibility Management, and Security Management. These insights highlight a clear need for better support and tooling to help practitioners manage provider updates more effectively, minimizing disruption while modernizing infrastructure. We recommend adopting automated dependency management tools and improved update workflows to reduce technical lag and lower the cost of staying up to date.

Software logging is the practice of recording different events that occur within a software system, which are useful for several analysis activities. However, striking the right balance between logging and system overhead is challenging. Prior work has conducted various machine learning-based solutions to suggest where to insert logging statements. But most importantly, before answering the question “where to log?’’, practitioners first need to determine whether a file needs logging at the first place. To do so, we conduct in this paper an empirical study to characterize the log density (i.e., ratio of log lines over the total lines of code) in seven open-source software projects. Then, we propose a deep learning based approach to predict the log density based on syntactic and semantic features of the source code. We find that the percentage of files with at least one log line ranges from 5% to 33% across the studied projects. Additionally, the median log density in the files with at least one log line ranges from 0.95% to 1.85% across the seven projects and can go up to 18%. Our findings resonate with the hypothesis that not all source code files require logging. On the other hand, our log density models achieve an average accuracy of 84%. Whereas our cross-project log density prediction results show a promising performance with an average accuracy of 72%, which represents over 86% (ratio of cross/within) of the corresponding within-project predictions using syntactic features. Our results show that we can accurately predict whether a file needs logging and such predictions may be generalized across projects.

Infrastructure-as-Code (IaC) constitutes a pivotal DevOps methodology, leading edge of software deployment onto cloud platforms. IaC relies on source code files rather than manual configuration to manage the infrastructure of a software system. Terraform, an IaC tool and its declarative configuration language named HCL, has recently garnered considerable attention among IaC practitioners. Like other software artefacts, Terraform files could be affected by misconfigurations, faults, and smells. Therefore, DevOps practitioners might benefit from a quality assurance tool to help them perform quality assurance activities on Terrafrom artefacts. This paper introduces TerraMetrics, an open-source tool designed to characterize the quality of Terraform artefacts by providing a catalogue of 40 quality metrics. TerraMetrics leverages the Terraform Abstract Syntax Tree (AST) to extract the metric list, offering a potentially enduring solution compared to conventional regular expressions. This tool comprises three main components: (i) a parser transforming HCL code into an AST, (ii) visitors that traverse the AST nodes to extract the metrics, and (iii) collectors for storing the collected metrics in JSON format. The TerraMetrics tool is publicly available as an Open Source tool, with a demo video, at: https://github.com/stilab-ets/terametrics.

Large Language Models (LLMs), like ChatGPT, have gained widespread popularity and usage in various software engineering tasks, including refactoring, testing, code review, and program comprehension. Despite recent studies delving into refactoring documentation in commit messages, issues, and code review, little is known about how developers articulate their refactoring needs when interacting with ChatGPT. In this paper, our goal is to explore conversations between developers and ChatGPT related to refactoring to better understand how developers identify areas for improvement in code and how ChatGPT addresses developers' needs. Our approach relies on text mining refactoring-related conversations from 17,913 ChatGPT prompts and responses, and investigating developers' explicit refactoring intention. Our results reveal that (1) developer-ChatGPT conversations commonly involve generic and specific terms/phrases; (2) developers often make generic refactoring requests, while ChatGPT typically includes the refactoring intention; and (3) various learning settings when prompting ChatGPT in the context of refactoring. We envision that our findings contribute to a broader understanding of the collaboration between developers and AI models.

Infrastructure-as-Code (IaC) is an emerging software engineering practice that leverages source code to facilitate automated configuration of software systems' infrastructure. IaC files are typically complex, containing hundreds of lines of code and dependencies, making them prone to defects, which can result in breaking online services at scale. To help developers early identify and fix IaC defects, research efforts have introduced IaC defect prediction models at the file level. However, the granularity of the proposed approaches remains coarse-grained, requiring developers to inspect hundreds of lines of code in a file, while only a small fragment of code is defective. To alleviate this issue, we introduce a machine-learning-based approach to predict IaC defects at a fine-grained level, focusing on IaC blocks, i.e., small code units that encapsulate specific behaviours within an IaC file. We trained various machine learning algorithms based on a mixture of code, process, and change-level metrics. We evaluated our approach on 19 open-source projects that use Terraform, a widely used IaC tool. The results indicated that there is no single algorithm that consistently outperforms the others in 19 projects. Overall, among the six algorithms, we observed that the LightGBM model achieved a higher average of 0.21 in terms of MCC and 0.71 in terms of AUC. Models analysis reveals that the developer's experience and the relative number of added lines tend to be the most important features. Additionally, we found that blocks belonging to the most frequent types are more prone to defects. Our defect prediction models have also shown sensitivity to concept drift, indicating that IaC practitioners should regularly retrain their models.

Nowadays, Large Language Models (LLMs) play a pivotal role in software engineering. Developers can use LLMs to address software development-related tasks such as documentation, code refactoring, debugging, and testing. ChatGPT, released by OpenAI, has become the most prominent LLM. In particular, ChatGPT is a cutting-edge tool for providing recommendations and solutions for developers in their pull requests (PRs). However, little is known about the characteristics of PRs that incorporate ChatGPT compared to those without it and what developers usually use it for. To this end, we quantitatively analyzed 243 PRs that listed at least one ChatGPT prompt against a representative sample of 384 PRs without any ChatGPT prompts. Our findings show that developers use ChatGPT in larger, time-consuming pull requests that are five times slower to be closed than PRs that do not use ChatGPT. Furthermore, we perform a qualitative analysis to build a taxonomy of the topics developers primarily address in their prompts. Our analysis results in a taxonomy comprising 8 topics and 32 sub-topics. Our findings highlight that ChatGPT is often used in review-intensive pull requests. Moreover, our taxonomy enriches our understanding of the developer's current applications of ChatGPT.

Modern code review (MCR) is recognized as an effective software quality assurance practice that is broadly adopted by open-source and commercial software projects. MCR is most effective when developers follow best practices, as it improves code quality, enhances knowledge transfer, increases team awareness and shares code ownership. However, prior work highlights that poor code review practices are common and often manifest in the form of low review participation and engagement, shallow review, and toxic communications. To address these issues, we introduce GitRev, a novel approach that applies gamification mechanisms to boost developer motivation and engagement. GitRev is built on top of a Large Language Model (LLM), used as a points-based reward system that leverages the code change context, and code review activities. We implement GitRev as a GitHub app with a web browser extension that consists of a client-side web browser extension that gamifies the GitHub user interface, and a server-side composed of a Node.js server for authentication and data management. To evaluate GitRev, we conduct a controlled experiment with 86 graduate and undergraduate students. Results indicate the promising potential of our approach for improving the code review process and developers' engagement. GitRev is publicly available at https://anonymous.40pen.science/r/GitRev-OB74

Although using third-party libraries has become prevalent in contemporary software development, developers often struggle to update their dependencies. Prior works acknowledge that due to the migration effort, priority and other issues cause lags in the migration process. The common assumption is that developers should drop all other activities and prioritize fixing the vulnerability. Our objective is to understand developer behavior when facing high-risk vulnerabilities in their code. We explore the prolific, and possibly one of the cases of the Log4JShell, a vulnerability that has the highest severity rating ever, which received widespread media attention. Using a mixed-method approach, we analyze 219 GitHub Pull Requests (PR) and 354 issues belonging to 53 Maven projects affected by the Log4JShell vulnerability. Our study confirms that developers show a quick response taking from 5 to 6 days. However, instead of dropping everything, surprisingly developer activities tend to increase for all pending issues and PRs. Developer discussions in-volved either giving information (29.3%) and seeking information (20.6%), which is missing in existing support tools. Leveraging this possibly-one of a kind event, insights opens up a new line of research, causing us to rethink best practices and what developers need in order to efficiently fix vulnerabilities.

With the urgent need to secure supply chains among Open Source libraries, attention has focused on mitigating vulnerabilities detected in these libraries. Although awareness has improved recently, most studies still report delays in the mitigation process. This suggests that developers still have to deal with other contributions that occur during the period of fixing vulnerabilities, such as coinciding Pull Requests (PRs) and Issues, yet the impact of these contributions remains unclear. To characterize these contributions, we conducted a mixed-method empirical study to analyze NPM GitHub projects affected by 554 different vulnerability advisories, mining a total of 4,699 coinciding PRs and Issues. We believe that tool development and improved workload management for developers have the potential to create a more efficient and effective vulnerability mitigation process.

Refactoring is the practice of improving software quality without altering its external behavior. Developers intuitively refactor their code for multiple purposes, such as improving program comprehension, reducing code complexity, dealing with technical debt, and removing code smells. However, no prior studies have exposed the students to an experience of the process of antipatterns detection and refactoring correction, and provided students with toolset to practice it. To understand and increase the awareness of refactoring concepts, in this paper, we aim to reflect on our experience with teaching refactoring and how it helps students become more aware of bad programming practices and the importance of correcting them via refactoring. This paper discusses the results of an experiment in the classroom that involved carrying out various refactoring activities for the purpose of removing antipatterns using JDeodorant, an IDE plugin that supports antipatterns detection and refactoring. The results of the quantitative and qualitative analysis with 171 students show that students tend to appreciate the idea of learning refactoring and are satisfied with various aspects of the JDeodorant plugin's operation. Through this experiment, refactoring can turn into a vital part of the computing educational plan. We envision our findings enabling educators to support students with refactoring tools tuned towards safer and trustworthy refactoring.

In modern software systems, Infrastructure-as-Code (IaC) tools play a pivotal role in automating the management of various infrastructure resources such as networks, databases, and services. This automation is done through code-based specification files, commonly known as IaC files. Similarly to other code files, IaC files can suffer from violations of established implementation and design standards, i.e., IaC smells. Although prior research has studied various aspects of traditional smells in non-IaC artifacts, there is little knowledge of how IaC smells are prevalent, co-occurring, and impacting the change and defect proneness of IaC code. To fill this gap, we conduct an empirical study encompassing 82 Puppet-based open-source projects. Our investigation focused on 12 types of IaC smells in both implementation and design levels. Our findings reveal that IaC smells do not manifest uniformly, as IaC smells that are particularly associated with modularity issues, exhibit high prevalence rates across projects. Additionally, we found that 74% of IaC files are smelly and over 52% of the smelly IaC files have at least two co-occurring IaC smells. Furthermore, our findings highlight that, on average, smelly IaC files are modified nearly 3.8 times, in terms of number of commits, more frequently than non-smelly IaC files. Furthermore, smelly IaC files are found to be 3.1 times more prone to larger code changes, in terms of code churn, than non-smelly IaC files. Additionally, we found that smelly IaC files are 3.3 times more prone to the introduction of defects that are likely to persist in 1.65 more commits before being fixed than non-smelly IaC files. These findings advocate developers to be more aware of IaC smells in their projects and consider their correction.

Abstract Refactoring is widely recognized as one of the efficient techniques to manage technical debt and maintain a healthy software project through enforcing best design practices, or coping with design defects. Previous refactoring surveys have shown that code refactoring activities are mainly executed by developers who have sufficient knowledge of the system's design, and disposing of leadership roles in their development teams. However, these surveys were mainly limited to specific projects and companies. In this paper, we explore the generalizability of the previous results by analyzing 800 open‐source projects. We mine their refactoring activities, and we identify their corresponding contributors. Then, we associate an experience score to each contributor in order to test various hypotheses related to whether developers with higher scores tend to (1) perform a higher number of refactoring operations, (2) exhibit different motivations behind their refactoring, and (3) better document their refactoring activity. We found that (1) although refactoring is not restricted to a subset of developers, those with higher contribution scores tend to perform more refactorings than others; (2) although there is no correlation between experience and motivation behind refactoring, top contributed developers are found to perform a wider variety of refactoring operations, regardless of their complexity; and (3) top contributed developer tend to document less their refactoring activity. Our qualitative analysis of three randomly sampled projects shows that the developers who are responsible for the majority of refactoring activities are typically in advanced positions in their development teams, demonstrating their extensive knowledge of the design of the systems they contribute to.

Modern software systems are designed to be deployed in different configured environments (e.g., permissions, virtual resources, network connections) and adapted at runtime to different situations (e.g., memory limits, enabling/disabling features, database credentials). Such a configuration during the deployment and runtime of a software system is implemented via a set of configuration files, which together constitute what we refer to as a “configuration system.” Recent research efforts investigated the evolution and maintenance of configuration files. However, they merely focused on a limited part of the configuration system (e.g., specific infrastructure configuration files or Dockerfiles), and their results do not generalize to the whole configuration system. To cope with such a limitation, we aim to better capture and understand what files constitute a configuration system. To do so, we leverage an open card sort technique to qualitatively study 1,756 configuration files from OpenStack, a large and widely studied open source software ecosystem. Our investigation reveals the existence of nine types of configuration files, which cover the creation of the infrastructure on top of which OpenStack will be deployed, along with other types of configuration files used to customize OpenStack after its deployment. These configuration files are interconnected while being used at different deployment stages. For instance, we observe specific configuration files used during the deployment stage to create other configuration files that are used in the runtime stage. We also observe that identifying and classifying these types of files is not straightforward, as five out of the nine types can be written in similar programming languages (e.g., Python and Bash) as regular source code files. We also found that the same file extensions (e.g., Yaml ) can be used for different configuration types, making it difficult to identify and classify configuration files. Thus, we first leverage a machine learning model to identify configuration from non-configuration files, which achieved a median area under the curve (AUC) of 0.91, a median Brier score of 0.12, a median precision of 0.86, and a median recall of 0.83. Thereafter, we leverage a multi-class classification model to classify configuration files based on the nine configuration types. Our multi-class classification model achieved a median weighted AUC of 0.92, a median Brier score of 0.04, a median weighted precision of 0.84, and a median weighted recall of 0.82. Our analysis also shows that with only 100 labeled configuration and non-configuration files, our model reached a median AUC higher than 0.69. Furthermore, our configuration model requires a minimum of 100 configuration files to reach a median weighted AUC higher than 0.75.

Modern Code Review (MCR) is an essential process in software development to ensure high-quality code. However, developers often spend considerable time reviewing code changes before being merged into the main code base. Previous studies attempted to predict whether a code change was going to be merged or abandoned soon after it was submitted to improve the code review process. However, these approaches require complex cost-sensitive learning, which makes their adoption challenging since it is difficult for developers to understand the main factors behind the models’ predictions. To address this issue, we introduce in this article, MULTICR , a multi-objective search-based approach that uses Multi-Objective Genetic Programming (MOGP) to learn early code review prediction models as IF-THEN rules. MULTICR evolves predictive models while maximizing the accuracy of both merged and abandoned classes, eliminating the need for misclassification cost estimation. To evaluate MULTICR, we conducted an empirical study on 146,612 code reviews from Eclipse, LibreOffice, and Gerrithub. The obtained results show that MULTICR outperforms existing baselines in terms of Matthew Correlation Coefficient (MCC) and F1 scores while learning less complex models compared to decision trees. Our experiments also showed how MULTICR allows identifying the main factors related to abandoned code reviews as well as their associated thresholds, making it a promising approach for early code review prediction with notable performance and inter-operability. Additionally, we qualitatively evaluate MULTICR by conducting a user study through semi-structured interviews involving 10 practitioners from different organizations. The obtained results indicate that 90% of the participants find that MULTICR is useful and can help them to improve the code review process. Additionally, the learned IF-THEN rules of MULTICR are transparent.

Background:Code refactoring is widely recognized as an essential software engineering practice to improve the understandability and maintainability of the source code. TheExtract Methodrefactoring is considered as “Swiss army knife” of refactorings, as developers often apply it to improve their code quality,e.g., decompose long code fragments, reduce code complexity, eliminate duplicated code, etc. In recent years, several studies attempted to recommendExtract Methodrefactorings allowing the collection, analysis, and revelation of actionable data-driven insights about refactoring practices within software projects.Aim:In this paper, we aim at reviewing the current body of knowledge on existing Extract Method refactoring research and explore their limitations and potential improvement opportunities for future research efforts. That is,Extract Methodis considered one of the most widely-used refactorings, but difficult to apply in practice as it involves low-level code changes such as statements, variables, parameters, return types, etc. Hence, researchers and practitioners begin to be aware of the state-of-the-art and identify new research opportunities in this context.Method:We review the body of knowledge related toExtract Methodrefactoring in the form of a systematic literature review (SLR). After compiling an initial pool of 1,367 papers, we conducted a systematic selection and our final pool included 83 primary studies. We define three sets of research questions and systematically develop and refine a classification schema based on several criteria including their methodology, applicability, and degree of automation.Results:The results construct a catalog of 83Extract Methodapproaches indicating that several techniques have been proposed in the literature. Our results show that: (i) 38.6% ofExtract Methodrefactoring studies primarily focus on addressing code clones; (ii) Several of theExtract Methodtools incorporate the developer’s involvement in the decision-making process when applying the method extraction, and (iii) the existing benchmarks are heterogeneous and do not contain the same type of information, making standardizing them for the purpose of benchmarking difficult.Conclusions:Our study serves as an “index” to the body of knowledge in this area for researchers and practitioners in determining theExtract Methodrefactoring approach that is most appropriate for their needs. Our findings also empower the community with information to guide the future development of refactoring tools.

During the last few years, Continuous Integration (CI) has become a common practice in open-source and industrial environments to reduce the scope for errors and increase the speed to market through the automated build and test processes. However, despite this wide adoption throughout the years, little is known about the challenges developers discuss. Analyzing the discussions of developers is required to understand what researchers, educators and practitioners should focus on, and how discussion communities can be helpful to shed the light on CI challenges. In this study, we examine Stack Overflow (SO), the most popular crowd-sourced forum, to understand the challenges developers face in the CI context. We collect a corpus of 27,728 CI-related developers posts from SO and analyze those posts through a mixed method with quantitative and qualitative analyzes. To study the trends of CI discussions, we investigated the metadata of CI questions, users and tags. Then, we extract the CI main topics using Latent Dirichlet Allocation (LDA) tuned with Genetic Algorithm (GA). Finally, we investigate the most popular and difficult topics faced by developers based on unanswered questions to get further insights into CI challenges. The LDA clustering reveals that developers face challenges with six main topics namely Build, Testing, Version Control, Configuration, Deployment, and CI Culture. Particularly, we found that the build topic is the most popular among the studied topics and that version control and testing topics are the most difficult for the SO community. Our study uncovers insights about CI challenges and adds evidence to existing knowledge about CI issues related especially to software build.

Background. Infrastructure-as-Code (IaC) is an emerging practice to manage cloud infrastructure resources for software systems. Modern software development has evolved to embrace IaC as a best practice for consistently provisioning and managing infrastructure using various tools such as Terraform and Ansible. However, recent studies highlighted that developers still encounter various challenges with IaC tools. Aims. We aim in this paper to understand the different challenges that developers encounter with IaC and analyze the trend of seeking assistance on Q&A platforms in the context of IaC. To this end, we conduct a large-scale empirical study investigating developers' discussions in Stack Overflow. Method. We first collect IaC-relevant tags on Stack Overflow, constituting a dataset that comprises 52,692 questions and 64,078 answers. Then, we group questions into specific topics using the Latent Dirichlet Allocation (LDA) method, which we optimize using a Genetic Algorithm (GA) for parameter's fine-tuning. Finally, to gain better insights, we analyze the identified topics based on different criteria such as popularity and difficulty. Results. Our findings reveal an average yearly increase of 150% in terms of IaC-related questions and 135% in terms of users between 2011 and 2022. Furthermore, we observe that IaC questions revolve around seven main topics: server configuration, policy configuration, networking, deployment pipelines, variable management, templating, and file management. Notably, we found that server configuration and file management are the most popular topics, i.e., the most discussed among IaC developers, while the deployment pipelines and templating topics are the most difficult. Conclusions. Our results shed light on IaC challenges that are often encountered by developers on popular Q&A platforms. These findings reveal important implications for practitioners seeking better support for IaC tools in real-world settings and for researchers to better understand the IaC community needs and further investigate IaC in different aspects.

Intelligent Transportation Systems are essential due to the increased number of traffic congestion problems and challenges nowadays. Traffic Signal Control (TSC) plays a critical role in optimizing the traffic flow and mitigating the congestion within the urban areas. Various research works have been conducted to enhance the behavior of TSCs at intersections and subsequently reduce the traffic congestion. Researchers recently leveraged Deep Learning (DL) and Reinforcement Learning (RL) techniques to optimize TSCs. In RL framework, the agent interacts with surrounding world through states, rewards and actions. The formulation of these key elements is crucial as they impact the way the RL agent behaves and optimizes its policy. However, most of existing frameworks rely on hand-crafted state and reward designs, restricting the RL agent from acting optimally. In this paper, we propose a novel approach to better formulate state and reward definitions in order to boost the performance of the traffic signal controller agent. The intuitive idea is to define both state and reward in a consistent and straightforward manner. We advocate that such a design approach helps achieving training stability and hence provides a rapid convergence to derive best policies. We consider the double deep Q-Network (DDQN) along with prioritized experience replay (PER) for the agent architecture. To evaluate the performance of our approach, we conduct series of simulations using the Simulation of Urban MObility (SUMO) environment. The statistical analysis of our results show that the performance of our proposal outperforms the state-of-the-art state and reward design approaches.

Abstract Open source software development is regarded as a collaborative activity in which developers interact to build a software product. Such a human collaboration is described as an organized effort of the “social” activity of organizations, individuals, and stakeholders, which can affect the development community and the open source project health. Negative effects of the development community manifest typically in the form of community smells, which represent symptoms of organizational and social issues within the open source software development community that often lead to additional project costs and reduced software quality. Recognizing the advantages of the early detection of potential community smells in a software project, we introduce a novel approach that learns from various community organizational, social, and emotional aspects to provide an automated support for detecting community smells. In particular, our approach learns from a set of interleaving organizational–social and emotional symptoms that characterize the existence of community smell instances in a software project. We build a multi‐label learning model to detect 10 common types of community smells. We use the ensemble classifier chain (ECC) model that transforms multi‐label problems into several single‐label problems, which are solved using genetic programming (GP) to find the optimal detection rules for each smell type. To evaluate the performance of our approach, we conducted an empirical study on a benchmark of 143 open source projects. The statistical tests of our results show that our approach can detect community smells with an average F‐measure of 93%, achieving a better performance compared to different state‐of‐the‐art techniques. Furthermore, we investigate the most influential community‐related metrics to identify each community smell type.

The rapid growth of mobile applications development and usage raises several new challenges to developers as they need to respond quickly to the users’ needs in a world of continuous changes. Developers often use third-party libraries to add functionality, which significantly improves developers productivity, and reduces time-to-market. In this paper, we present an approach for the visualization and recommendation of libraries for Android apps. Our approach, named LibScanDroid, is based on how libraries are used within existing Android applications. LibScanDroid groups together libraries based on their history of joint and separate usage in existing Android applications available in Google Play Store. The library groups, i.e., usage patterns, are presented in several layers to visualize and navigate through the patterns. These groupings are performed using the ϵ-DBSCAN hierarchical clustering algorithm.We implement our approach in the form of an interactive tool and evaluate it on a database that covers 1,458 libraries that are used by over 1,000 Android applications. Our experiments have shown that our approach can detect library patterns with high co-usage cohesion. The results from the cross-validation, allows us to affirm the generalizability of the detected patterns.

Third-party library dependencies are commonplace in today’s software development. With the growing threat of security vulnerabilities, applying security fixes in a timely manner is important to protect software systems. As such, the community developed a list of software and hardware weakness known as Common Weakness Enumeration (CWE) to assess vulnerabilities. Prior work has revealed that maintenance activities such as refactoring code potentially correlate with security-related aspects in the source code. In this work, we explore the relationship between refactoring and security by analyzing refactoring actions performed jointly with vulnerability fixes in practice. We conducted a case study to analyze 143 maven libraries in which 351 known vulnerabilities had been detected and fixed. Surprisingly, our exploratory results show that developers incorporate refactoring operations in their fixes, with 31.9% (112 out of 351) of the vulnerabilities paired with refactoring actions. We envision this short paper to open up potential new directions to motivate automated tool support, allowing developers to deliver fixes faster, while maintaining their code.

The microservices architectural style offers many advantages such as scalability, reusability and ease of maintainability. As such microservices has become a common architectural choice when developing new applications. Hence, to benefit from these advantages, monolithic applications need to be redesigned in order to migrate to a microservice based architecture. Due to the inherent complexity and high costs related to this process, it is crucial to automate this task. In this paper, we propose a method that can identify potential microservices from a given monolithic application. Our method takes as input the source code of the source application in order to measure the similarities and dependencies between all of the classes in the system using their interactions and the domain terminology employed within the code. These similarity values are then used with a variant of a density-based clustering algorithm to generate a hierarchical structure of the recommended microservices while identifying potential outlier classes. We provide an empirical evaluation of our approach through different experimental settings including a comparison with existing human-designed microservices and a comparison with 5 baselines. The results show that our method succeeds in generating microservices that are overall more cohesive and that have fewer interactions in-between them with up to 0.9 of precision score when compared to human-designed microservices.

We developed a plugin for IntelliJ IDEA called AntiCopyPaster, which tracks the pasting of code fragments inside the IDE and suggests the appropriate Extract Method refactoring to combat the propagation of duplicates. Unlike the existing approaches, our tool is integrated with the developer’s workflow, and pro-actively recommends refactorings. Since not all code fragments need to be extracted, we develop a classification model to make this decision. When a developer copies and pastes a code fragment, the plugin searches for duplicates in the currently opened file, waits for a short period of time to allow the developer to edit the code, and finally inferences the refactoring decision based on a number of features.

Modern code review is a widely used technique employed in both industrial and open-source projects to improve software quality, share knowledge, and ensure adherence to coding standards and guidelines. During code review, developers may discuss refactoring activities before merging code changes in the code base. To date, code review has been extensively studied to explore its general challenges, best practices and outcomes, and socio-technical aspects. However, little is known about how refactoring is being reviewed and what developers care about when they review refactored code. Hence, in this work, we present a quantitative and qualitative study to understand what are the main criteria developers rely on to develop a decision about accepting or rejecting a submitted refactored code, and what makes this process challenging. Through a case study of 11,010 refactoring and non-refactoring reviews spread across OpenStack open-source projects, we find that refactoring-related code reviews take significantly longer to be resolved in terms of code review efforts. Moreover, upon performing a thematic analysis on a significant sample of the refactoring code review discussions, we built a comprehensive taxonomy consisting of 28 refactoring review criteria. We envision our findings reaffirming the necessity of developing accurate and efficient tools and techniques that can assist developers in the review process in the presence of refactorings.

Understanding the practice of refactoring documentation is of paramount importance in academia and industry. Issue tracking systems are used by most software projects enabling developers, quality assurance, managers, and users to submit feature requests and other tasks such as bug fixing and code review. Although recent studies explored how to document refactoring in commit messages, little is known about how developers describe their refactoring needs in issues. In this study, we aim at exploring developer-reported refactoring changes in issues to better understand what developers consider to be problematic in their code and how they handle it. Our approach relies on text mining 45,477 refactoring-related issues and identifying refactoring patterns from a diverse corpus of 77 Java projects by investigating issues associated with 15,833 refactoring operations and developers' explicit refactoring intention. Our results show that (1) developers mostly use move refactoring related terms/phrases to target refactoring-related issues; and (2) developers tend to explicitly mention the improvement of specific quality attributes and focus on duplicate code removal. We envision our findings enabling tool builders to support developers with automated documentation of refactoring changes in issues.

Web service composition allows developers to create applications via reusing available services that are interoperable to each other. The process of selecting relevant Web services for a composite service satisfying the developer requirements is commonly acknowledged to be hard and challenging, especially with the exponentially increasing number of available Web services on the Internet. The majority of existing approaches on Web Services Selection are merely based on the Quality of Service (QoS) as a basic criterion to guide the selection process. However, existing approaches tend to ignore the service design quality, which plays a crucial role in discovering, understanding, and reusing service functionalities. Indeed, poorly designed Web service interfaces result in service anti-patterns, which are symptoms of bad design and implementation practices. The existence of anti-pattern instances in Web service interfaces typically complicates their reuse in real-world service-based systems and may lead to several maintenance and evolution problems. To address this issue, we introduce a new approach based on the Multi-Objective and Optimization on the basis of Ratio Analysis method (MOORA) as a multi-criteria decision making (MCDM) method to select Web services based on a combination of their (1) QoS attributes and (2) QoS design. The proposed approach aims to help developers to maintain the soundness and quality of their service composite development processes. We conduct a quantitative and qualitative empirical study to evaluate our approach on a Quality of Web Service dataset. We compare our MOORA-based approach against four commonly used MCDM methods as well as a recent state-of-the-art Web service selection approach. The obtained results show that our approach outperforms state-of-the-art approaches by significantly improving the service selection quality of top- k selected services while providing the best trade-off between both service design quality and desired QoS values. Furthermore, we conducted a qualitative evaluation with developers. The obtained results provide evidence that our approach generates a good trade-off for what developers need regarding both QoS and quality of design. Our selection approach was evaluated as “relevant” from developers point of view, in improving the service selection task with an average score of 3.93, compared to an average of 2.62 for the traditional QoS-based approach.

Continuous Integration (CI) consists of integrating the changes introduced by different developers more frequently through the automation of build process. Nevertheless, the CI build process is seen as a major barrier that causes delays in the product release dates. One of the main reasons for such delays is that some simple changes (i.e., can be skipped) trigger the build, which represents an unnecessary overhead and particularly painful for large projects. In order to cut off the expenses of CI build time, we propose in this paper,SkipCI, a novel search-based approach to automatically detect CI Skip commits based on the adaptation of Strength-Pareto Evolutionary Algorithm (SPEA-2). Our approach aims to provide the optimal trade-off between two conflicting objectives to deal with both skipped and non-skipped commits. We evaluate our approach and investigate the performance of both within and cross-project validations on a benchmark of 14,294 CI commits from 15 projects that use Travis CI system. The statistical tests revealed that our approach shows a clear advantage over the baseline approaches with average scores of 92% and 84% in terms of AUC for cross-validation and cross-project validations respectively. Furthermore, the features analysis reveals that documentation changes, terms appearing in the commit message and the committer experience are the most prominent features in CI skip detection. When it comes to the cross-project scenario, the results reveal that besides the documentation changes, there is a strong link between current and previous commits results. Moreover, we deployed and evaluated the usefulness ofSkipCIwith our industrial partner. Qualitative results demonstrate the effectiveness ofSkipCIin providing relevant CI skip commit recommendations to developers for two large software projects from practitioner’s point of view.

Test smells are defined as sub-optimal design choices developers make when implementing test cases. Hence, similar to code smells, the research community has produced numerous test smell detection tools to investigate the impact of test smells on the quality and maintenance of test suites. However, little is known about the characteristics, type of smells, target language, and availability of these published tools. In this paper, we provide a detailed catalog of all known, peer-reviewed, test smell detection tools.

Community smells represent symptoms of sub-optimal organizational and social issues within software development communities that often lead to additional project costs and reduced software quality. Previous research identified a variety of community smells that are connected to sub-optimal patterns under different perspectives of organizational-social structures in the software development community. To detect community smells and understanding the characteristics of such organizational-social structures in a project, we propose csDetector, an open source tool that is able to automatically detect community smells within a project and provide relevant socio-technical metrics. csDetector uses a machine learning based detection approach that learns from various existing bad community development practices to provide automated support in detecting related community smells. We evaluate the effectiveness of csDetector on a benchmark of 143 open source projects from GitHub. Our results show that the csDetector tool can detect ten commonly occurring community smells in open software projects with an average F1 score of 84%. csDetector is publicly available, with a demo video, at: https://github.com/Nuri22/csDetector.

Continuous Integration (CI) aims at supporting developers in inte-grating code changes quickly through automated building. How-ever, there is a consensus that CI build failure is a major barrierthat developers face, which prevents them from proceeding furtherwith development. In this paper, we introduceBF-Detector, anautomated tool to detect CI build failure. Based on the adaptationof Non-dominated Sorting Genetic Algorithm (NSGA-II), our toolaims at finding the best prediction rules based on two conflictingobjective functions to deal with both minority and majority classes.We evaluated the effectiveness of our tool on a benchmark of 56,019CI builds. The results reveal that our technique outperforms state-of-the-art approaches by providing a better balance between bothfailed and passed builds.BF-Detectortool is publicly available,with a demo video, at: https://github.com/stilab-ets/BF-Detector.

Modern code review (MCR) is now broadly adopted as an established and effective software quality assurance practice, with an increasing number of open-source as well as commercial software projects identifying code review as a crucial practice. During the MCR process, developers review, provide constructive feedback, and/or critique each others’ patches before a code change is merged into the codebase. Nevertheless, code review is basically a human task that involves technical, personal and social aspects. Existing literature hint the existence of poor reviewing practices i.e., anti-patterns, that may contribute to a tense reviewing culture, degradation of software quality, slow down integration, and may affect the overall sustainability of the project. To better understand these practices, we present in this paper the concept of Modern Code Review Anti-patterns (MCRA) and take a first step to define a catalog that enumerates common poor code review practices. In detail we explore and characterize MCRA symptoms, causes, and impacts. We also conduct a series of preliminary experiments to investigate the prevalence and co-occurrences of such anti-patterns on a random sample of 100 code reviews from various OpenStack projects.

The concept of Self-Affirmed Refactoring (SAR) was introduced to explore how developers document their refactoring activities in commit messages, i.e., developers explicit documentation of refactoring operations intentionally introduced during a code change. In our previous study, we have manually identified refactoring patterns and defined three main common quality improvement categories including internal quality attributes, external quality attributes, and code smells, by only considering refactoring-related commits. However, this approach heavily depends on the manual inspection of commit messages. In this paper, we propose a two-step approach to first identify whether a commit describes developer-related refactoring events, then to classify it according to the refactoring common quality improvement categories. Specifically, we combine the N-Gram TF–IDF feature selection with binary and multiclass classifiers to build a new model to automate the classification of refactorings based on their quality improvement categories. We challenge our model using a total of 2,867 commit messages extracted from well engineered open-source Java projects. Our findings show that (1) our model is able to accurately classify SAR commits, outperforming the pattern-based and random classifier approaches, and allowing the discovery of 40 more relevant SAR patterns, and (2) our model reaches an F-measure of up to 90% even with a relatively small training dataset.

Successful Web services evolve through a process of continuous change due to several reasons such as improving the quality, fixing bugs and adding new features. However, this evolution process may weaken the design of the Web service's interface by aggregating many non-cohesive and semantically unrelated operations. Thus, the service interface becomes unnecessarily complex for users to find relevant operations to be used by their services-based systems. In this paper, we propose an interactive recommendation approach, based on evolutionary algorithms, that dynamically adapts and suggests a possible remodularization of the Web services interface design to users/developers and takes their feedback into consideration. Our approach uses an interactive multi-criteria decision-making algorithm, based on interactive Non-dominated Sorting Genetic Algorithm (NSGA-II), to find a set of good design interface modularization solutions. These solutions provide a trade-off between improving several interface design quality metrics (e.g., coupling, cohesion, number of port types, and number of antipatterns) and fix Web services design antipatterns, maximizing the satisfaction of the interaction constraints learnt from the user feedback during the execution of the algorithm while minimizing the deviation from the initial design. We evaluated our approach on a set of 22 real world Web services, provided by Amazon and Yahoo. Statistical analysis of our experiments shows that our dynamic interactive Web services interface modularization approach performed significantly better than the state-of-the-art modularization techniques in terms of generating well-designed Web services interface for users.

Community smells are symptoms of organizational and social issues within the software development community that often increase the project costs and impact software quality. Recent studies have identified a variety of community smells and defined them as suboptimal patterns connected to organizational-social structures in the software development community such as the lack of communication, coordination and collaboration. Recognizing the advantages of the early detection of potential community smells in a software project, we introduce a novel approach that learns from various community organizational and social practices to provide an automated support for detecting community smells. In particular, our approach learns from a set of interleaving organizational-social symptoms that characterize the existence of community smell instances in a software project. We build a multi-label learning model to detect 8 common types of community smells. We use the ensemble classifier chain (ECC) model that transforms multi-label problems into several single-label problems which are solved using genetic programming (GP) to find the optimal detection rules for each smell type. To evaluate the performance of our approach, we conducted an empirical study on a benchmark of 103 open source projects and 407 community smell instances. The statistical tests of our results show that our approach can detect the eight considered smell types with an average F-measure of 89% achieving a better performance compared to different state-of-the-art techniques. Furthermore, we found that the most influential factors that best characterize community smells include the social network density and closeness centrality as well as the standard deviation of the number of developers per time zone and per community.

The test code, just like production source code, is subject to bad design and programming practices, also known as smells. The presence of test smells in a software project may affect the quality, maintainability, and extendability of test suites making them less effective in finding potential faults and quality issues in the project's production code. In this paper, we introduce tsDetect, an automated test smell detection tool for Java software systems that uses a set of detection rules to locate existing test smells in test code. We evaluate the effectiveness of tsDetect on a benchmark of 65 unit test files containing instances of 19 test smell types. Results show that tsDetect achieves a high detection accuracy with an average precision score of 96% and an average recall score of 97%. tsDetect is publicly available, with a demo video, at: https://testsmells.github.io/

Successful software products evolve through a process of continual change. However, this process may weaken the design of the software and make it unnecessarily complex, leading to significantly reduced productivity and increased fault-proneness. Refactoring improves the software design while preserving overall functionality and behavior, and is an important technique in managing the growing complexity of software systems. Most of the existing work on software refactoring uses either an entirely manual or a fully automated approach. Manual refactoring is time-consuming, error-prone and unsuitable for large-scale, radical refactoring. On the other hand, fully automated refactoring yields a static list of refactorings which, when applied, leads to a new and often hard to comprehend design. Furthermore, it is difficult to merge these refactorings with other changes performed in parallel by developers. In this paper, we propose a refactoring recommendation approach that dynamically adapts and interactively suggests refactorings to developers and takes their feedback into consideration. Our approach uses NSGA-II to find a set of good refactoring solutions that improve software quality while minimizing the deviation from the initial design. These refactoring solutions are then analyzed to extract interesting common features between them such as the frequently occurring refactorings in the best non-dominated solutions. Based on this analysis, the refactorings are ranked and suggested to the developer in an interactive fashion as a sequence of transformations. The developer can approve, modify or reject each of the recommended refactorings, and this feedback is then used to update the proposed rankings of recommended refactorings. After a number of introduced code changes and interactions with the developer, the interactive NSGA-II algorithm is executed again on the new modified system to repair the set of refactoring solutions based on the new changes and the feedback received from the developer. We evaluated our approach on a set of eight open source systems and two industrial projects provided by an industrial partner. Statistical analysis of our experiments shows that our dynamic interactive refactoring approach performed significantly better than four existing search-based refactoring techniques and one fully-automated refactoring tool not based on heuristic search.

Background. Refactoring is a critical task in software maintenance and is generally performed to enforce the best design and implementation practices or to cope with design defects. Several studies attempted to detect refactoring activities through mining software repositories allowing to collect, analyze and get actionable data-driven insights about refactoring practices within software projects. Aim. We aim at identifying, among the various quality models presented in the literature, the ones that are more in-line with the developer's vision of quality optimization, when they explicitly mention that they are refactoring to improve them. Method. We extract a large corpus of design-related refactoring activities that are applied and documented by developers during their daily changes from 3,795 curated open source Java projects. In particular, we extract a large-scale corpus of structural metrics and anti-pattern enhancement changes, from which we identify 1,245 quality improvement commits with their corresponding refactoring operations, as perceived by software engineers. Thereafter, we empirically analyze the impact of these refactoring operations on a set of common state-of-the-art design quality metrics. Results. The statistical analysis of the obtained results shows that (i) a few state-of-the-art metrics are more popular than others; and (ii) some metrics are being more emphasized than others. Conclusions. We verify that there are a variety of structural metrics that can represent the internal quality attributes with different degrees of improvement and degradation of software quality. Most of the metrics that are mapped to the main quality attributes do capture developer intentions of quality improvement reported in the commit messages.

In this paper we introduce, MigrationMiner, an automated tool that detects code migrations performed between Java third-party library. Given a list of open source projects, the tool detects potential library migration code changes and collects the specific code fragments in which the developer replaces methods from the retired library with methods from the new library. To support the migration process, MigrationMiner collects the library documentation that is associated with every method involved in the migration. We evaluate our tool on a benchmark of manually validated library migrations. Results show that MigrationMiner achieves an accuracy of 100%. A demo video of Migration-Miner is available at https://youtu.be/sAlR1HNetXc.

The migration process between different third-party libraries is hard, complex and error-prone. Typically, during a library migration, developers need to find methods in the new library that are most adequate in replacing the old methods of the retired library. This process is subjective and time-consuming as developers need to fully understand the documentation of both libraries' Application Programming Interfaces, and find the right matching between their methods, if it exists. In this context, several studies rely on mining existing library migrations to provide developers with by-example approaches for similar scenarios. In this paper, we introduce a novel mining approach that extracts existing instances of library method replacements that are manually performed by developers for a given library migration to automatically generate migration patterns in the method level. Thereafter, our approach combines the mined method-change patterns with method-related lexical similarity to accurately detect mappings between replacing/replaced methods. We conduct a large scale empirical study to evaluate our approach on a benchmark of 57,447 open-source Java projects leading to 9 popular library migrations. Our qualitative results indicate that our approach significantly increases the accuracy of mining method-level mappings by an average accuracy of 12%, as well as increasing the number of discovered method mappings, in comparison with existing state-of-the-art studies. Finally, we provide the community with an open source mining tool along with a dataset of all mined migrations at the method level.

A key success of a Web service is to appropriately design its interface to make it easy to consume and understand. In the context of service-oriented computing (SOC), the service’s interface is the main source of interaction with the consumers to reuse the service functionality in real-world applications. The SOC paradigm provides a collection of principles and guidelines to properly design services to provide best practice of third-party reuse. However, recent studies showed that service designers tend to pay little care to the design of their service interfaces, which often lead to several side effects known as antipatterns . One of the most common Web service interface antipatterns is to expose a large number of semantically unrelated operations, implementing different abstractions, in one single interface. Such bad design practices may have a significant impact on the service reusability, understandability, as well as the development and run-time characteristics. To address this problem, in this article, we propose a hybrid approach to improve the design quality of Web service interfaces and fix antipatterns as a combination of both deterministic and heuristic-based approaches. The first step consists of a deterministic approach using a graph partitioning-based technique to split the operations of a large service interface into more cohesive interfaces, each one representing a distinct abstraction. Then, the produced interfaces will be checked using a heuristic-based approach based on the non-dominated sorting genetic algorithm (NSGA-II) to correct potential antipatterns while reducing the interface design deviation to avoid taking the service away from its original design. To evaluate our approach, we conduct an empirical study on a benchmark of 26 real-world Web services provided by Amazon and Yahoo. Our experiments consist of a quantitative evaluation based on design quality metrics, as well as a qualitative evaluation with developers to assess its usefulness in practice. The results show that our approach significantly outperforms existing approaches and provides more meaningful results from a developer’s perspective.

Refactoring is a highly valuable solution to reduce and manage the growing complexity of software systems. However, programmers are "opportunistic" when they apply refactorings since most of them are interested in improving the quality of the code fragments that they frequently update or those related to the planned activities for the next release (fixing bugs, adding new functionalities, etc.). In this paper, we describe a search based approach to recommend refactorings based on the analysis of the history of changes to maximize the recommended refactorings for recently modified classes, classes containing incomplete refactorings detected in previous releases, and buggy classes identified in the history of previous bug reports. The obtained results on two industrial projects show significant improvements of the relevance of recommended refactorings, as evaluated by the original developers of the systems.

Design defects are symptoms of poor design and implementation solutions adopted by developers during the development of their software systems. While the research community devoted a lot of effort to studying and devising approaches for detecting the traditional design defects in object-oriented (OO) applications, little knowledge and support is available for an emerging category of Web service interface design defects. Indeed, it has been shown that service designers and developers tend to pay little attention to their service interfaces design. Such design defects can be subjectively interpreted and hence detected in different ways. In this paper, we propose a novel approach, named WS3D, using machine learning techniques that combines Support Vector Machine (SVM) and Simulated Annealing (SA) to learn from real world examples of service design defects. WS3D has been empirically evaluated on a benchmark of Web services from 14 different application domains. We compared WS3D with the state-of-theart approaches which rely on traditional declarative techniques to detect service design defects by combining metrics and threshold values. Results show that WS3D outperforms the the compared approaches in terms of accuracy with a precision and recall scores of 91% and 94%, respectively.

In the service-oriented paradigm, Web service interfaces are considered contracts between Web service subscribers and providers. The structure of service interfaces has an extremely important role to discover, understand, and reuse Web services. However, it has been shown that service developers tend to pay little care to the design of their interfaces. A common design issue that often appears in real-world Web services is that their interfaces lack cohesion, i.e., they expose several operations that are often semantically unrelated. Such a bad design practice may significantly complicate the comprehension and reuse of the services functionalities and lead to several maintenance and evolution problems. In this paper, we propose a new approach for Web service interface decomposition using a Formal Concept Analysis (FCA) framework. The proposed FCA-based approach aims at identifying the hidden relationships among service operations in order to improve the interface modularity and usability. The relationships between operations are based on cohesion measures including semantic, sequential and communicational cohesion. The identified groups of semantically related operations having common properties are used to define new cohesive and loosely coupled service interfaces. We conducted a quantitative and qualitative empirical study to evaluate our approach on a benchmark of 26 real world Web services provided by Amazon and Yahoo. The obtained results show that our approach can significantly improve Web service interface design quality compared to state-of-the-art approaches.

Web services evolve over time to fix bugs or update and add new features. However, the design of the Web service's interface may become more complex when aggregating many unrelated operations in terms of context and functionalities. A possible solution is to refactor the Web services interface into different modules that help the user quickly identifying relevant operations. The most challenging issue when refactoring a Web services interface is the high number of possible modularization solutions. The evaluation of these solutions is subjective and difficult to quantify. This paper introduces the use of a neural network-based evaluation function for the problem of Web services interface modularization. The users evaluate manually the suggested modularization solutions by a Genetic Algorithm (GA) for a number of iterations then an Artificial Neural Network (ANN) uses these training examples to evaluate the proposed Web services design changes for the remaining iterations. We evaluated the efficiency of our approach using a benchmark of 82 Web services from different domains and compared the performance of our technique with several existing Web services modularization studies in terms of generating well-designed Web services interface for users.

Service-Oriented Architectures (SOAs) successfully evolve over time to update existing exposed features to the users and fix possible bugs. This evolution process may have a negative impact on the design quality of Web services. Recent studies addressed the problem of Web service antipatterns detection (bad design practices). To the best of our knowledge, these studies focused only on the use of metrics extracted from the implementation details (source code) of the interface and the services. However, the quality of service (QoS) metrics, widely used to evaluate the overall performance, are never used in the context of Web service antipatterns detection. We start, in this work, from the hypothesis that these bad design practices may impact several QoS metrics such as the response time. Furthermore, the source code metrics of services may not be always available. Without the consideration of these QoS metrics, the current detection processes of antipatterns will still lack the integration of symptoms that could be extracted from the usage of services. In this paper, we propose an automated approach to generate Web service defect detection rules that consider not only the code/interface level metrics but also the quality of service attributes. Through multi-objective optimization, the proposed approach generates solutions (detection rules) that maximize the coverage of antipattern examples and minimize the coverage of well-designed service examples. An empirical validation is performed with eight different common types of Web design defects to evaluate our approach. We compared our results with three other state of the art techniques which are not using QoS metrics. The statistical analysis of the obtained results confirm that our approach outperforms other techniques and generates detection rules that are more meaningful from the services' user perspective.

In recent times, use of third-party libraries has become prevalent practice in contemporary software development. Much like other code components, unmaintained libraries are a cause for concern, especially when it risks code degradation over time. Therefore, awareness of when a library should be updated is important. With the emergence of large libraries hosting repositories such as Maven Central, we can leverage the dynamics of these ecosystems to understand and estimate when a library is due for an update. In this paper, based on the concepts of software aging, we empirically explore library usage as a means to describe its age. The study covers about 1,500 libraries belonging to the Maven software ecosystem. Results show that library usage changes are not random, with 81.7% of the popular libraries fitting typical polynomial models. Further analysis show that ecosystem factors such as emerging rivals has an effect on aging characteristics. Our preliminary findings demonstrate that awareness of library aging and its characteristics is a promising step towards aiding client systems in the maintenance of their libraries.

We propose, in this paper, a lightweight refactoring recommendation tool, namely c-JRefRec, to identify Move Method refactoring opportunities based on four heuristics using static and semantic program analysis. Our tool aims at identiying refactoring opportunities before a code change is committed to the codebase based on current code changes whenever the developer saves/compiles his code. We evaluate the efficiency of our approach in detecting Feature Envy smells and recommending Move Method refactorings to fix them on three Java open-source systems and 30 code changes. Results show that our approach achieves an average precision of 0.48 and 0.73 of recall and outperforms a state-of-the-art approach namely JDeodorant.

Refactoring is widely recognized as a crucial technique applied when evolving object‐oriented software systems. If applied well, refactoring can improve different aspects of software quality including readability, maintainability, and extendibility. However, despite its importance and benefits, recent studies report that automated refactoring tools are underused much of the time by software developers. This paper introduces an automated approach for refactoring recommendation, called MORE, driven by 3 objectives: (1) to improve design quality (as defined by software quality metrics), (2) to fix code smells, and (3) to introduce design patterns. To this end, we adopt the recent nondominated sorting genetic algorithm, NSGA‐III, to find the best trade‐off between these 3 objectives. We evaluated the efficacy of our approach using a benchmark of 7 medium and large open‐source systems, 7 commonly occurring code smells (god class, feature envy, data class, spaghetti code, shotgun surgery, lazy class, and long parameter list), and 4 common design pattern types (visitor, factory method, singleton, and strategy). Our approach is empirically evaluated through a quantitative and qualitative study to compare it against 3 different state‐of‐the art approaches, 2 popular multiobjective search algorithms, and random search. The statistical analysis of the results confirms the efficacy of our approach in improving the quality of the studied systems while successfully fixing 84% of code smells and introducing an average of 6 design patterns. In addition, the qualitative evaluation shows that most of the suggested refactorings (an average of 69%) are considered by developers to be relevant and meaningful.

Service Oriented Architecture (SOA) is widely used in industry and is regarded as one of the preferred architectural design technologies. As with any other software system, service-based systems (SBSs) may suffer from poor design, i.e., antipatterns, for many reasons such as poorly planned changes, time pressure or bad design choices. Consequently, this may lead to an SBS product that is difficult to evolve and that exhibits poor quality of service (QoS). Detecting web service antipatterns is a manual, time-consuming and error-prone process for software developers. In this paper, we propose an automated approach for detection of web service antipatterns using a cooperative parallel evolutionary algorithm (P-EA). The idea is that several detection methods are combined and executed in parallel during an optimization process to find a consensus regarding the identification of web service antipatterns. We report the results of an empirical study using eight types of common web service antipatterns. We compare the implementation of our cooperative P-EA approach with random search, two single population-based approaches and one state-of-the-art detection technique not based on heuristic search. Statistical analysis of the obtained results demonstrates that our approach is efficient in antipattern detection, with a precision score of 89 percent and a recall score of 93 percent.

Code review is of primary importance in modern software development. It is widely recognized that peer review is an efficient and effective practice for improving software quality and reducing defect proneness. For successful review process, peer reviewers should have a deep experience and knowledge with the code being reviewed, and familiar to work and collaborate together. However, one of the main challenging tasks in modern code review is to find the most appropriate reviewers for submitted code changes. So far, reviewers assignment is still a manual, costly and time-consuming task. In this paper, we introduce a search-based approach, namely RevRec, to provide decision-making support for code change submitters and/or reviewers assigners to identify most appropriate peer reviewers for their code changes. RevRec aims at finding reviewers to be assigned for a code change based on their expertise and collaboration in past reviews using genetic algorithm (GA). We evaluated our approach on a benchmark of three open-source software systems, Android, OpenStack, and Qt. Results indicate that RevRec accurately recommends code reviewers with up to 59% of precision and 74% of recall. Our experiments provide evidence that leveraging reviewers expertise from their prior reviews and the socio-technical aspects of the team work and collaboration is relevant in improving the performance of peer reviewers recommendation in modern code review.

Service interface structure is of primary importance in SOA to ensure best practice of third-party reuse. One of the key factors for deploying successful services is assuring an adequate interface structure. However, a common bad service design practice is to place semantically unrelated operations in a single interface. This poor design practice typically result in a system which is difficult to comprehend, maintain and evolve providing low performance and reusability. To address this problem, we present an automated approach, SIM, to support service developers improve the quality of their interface modularization. Our approach analyzes structural and semantic relationships among the operations exposed in a service interface to identify chains of strongly related operations. The identified operation chains are used to define new interfaces with higher cohesion and better usability. We empirically evaluate our approach on a benchmark of 22 realworld Web services, provided by Amazon and Yahoo. The obtained results show that the produced interfaces are (i) able to improve the service design quality, and (ii) recognized as 'useful' from developers point of view in improving their service design. Additionally, we found that SIM significantly outperforms a recent state-of-the-art approach.

We propose, in this paper, to consider the problemof Web service antipatterns detection as a multi-objectiveproblem where examples of Web service antipatterns and welldesignedcode are used to generate detection rules. To thisend, we use multi-objective genetic programming (MOGP)to find the best combination of metrics that maximizes thedetection of Web service antipattern examples and minimizesthe detection of well-designed Web service design examples. We report the results of an empirical study using 8 differenttypes of common Web service antipatterns. We compared ourmulti-objective formulation with random search, one existingmono-objective approach, and one state-of-the-art detectiontechnique not based on heuristic search. Statistical analysis ofthe obtained results demonstrates that our approach is efficientin antipattern detection, on average, with a precision score of94% and a recall score of 92%.

Refactoring is a critical technique in evolving software systems. Martin Fowler presented a catalogue of refactoring patterns that defines a list of code smells and their corresponding refactoring patterns. This list aimed at supporting programmers in finding suitable refactoring patterns that remove code smells from their systems. However, a recent empirical study by Bavota et al. shows that refactoring rarely removes code smells which do not align with Fowler's catalog. To bridge the gap between them, we revisit the relationship between code smells and refactorings. In this study, we investigate whether developers apply appropriate refactoring patterns to fix code smells in three open source software systems.

Developers may follow a tedious process to find the cause of a bug based on code reviews and reproducing the abnormal behavior. In this paper, we propose an automated approach to finding and ranking potential classes with the respect to the probability of containing a bug based on a bug report description. Our approach finds a good balance between minimizing the number of recommended classes and maximizing the relevance of the proposed solution using a multi-objective optimization algorithm. The relevance of the recommended classes (solution) is estimated based on the use of the history of changes and bug-fixing, and the lexical similarity between the bug report description and the API documentation. We evaluated our system on 6 open source Java projects, using the version of the project before fixing the bug of many bug reports. The experimental results show that the search-based approach significantly outperforms three state-of-the-art methods in recommending relevant files for bug reports. In particular, our multi-objective approach is able to successfully locate the true buggy methods within the top 10 recommendations for over 87% of the bug reports.

One of the most widely used techniques to improve the quality of existing software systems is refactoring—the process of improving the design of existing code by changing its internal structure without altering its external behavior. While it is important to suggest refactorings that improve the quality and structure of the system, many other criteria are also important to consider, such as reducing the number of code changes, preserving the semantics of the software design and not only its behavior, and maintaining consistency with the previously applied refactorings. In this article, we propose a multi-objective search-based approach for automating the recommendation of refactorings. The process aims at finding the optimal sequence of refactorings that (i) improves the quality by minimizing the number of design defects, (ii) minimizes code changes required to fix those defects, (iii) preserves design semantics, and (iv) maximizes the consistency with the previously code changes. We evaluated the efficiency of our approach using a benchmark of six open-source systems, 11 different types of refactorings (move method, move field, pull up method, pull up field, push down method, push down field, inline class, move class, extract class, extract method, and extract interface) and six commonly occurring design defect types (blob, spaghetti code, functional decomposition, data class, shotgun surgery, and feature envy) through an empirical study conducted with experts. In addition, we performed an industrial validation of our technique, with 10 software engineers, on a large project provided by our industrial partner. We found that the proposed refactorings succeed in preserving the design coherence of the code, with an acceptable level of code change score while reusing knowledge from recorded refactorings applied in the past to similar contexts.

Service-Oriented Architecture (SOA) is an emerging paradigm that has radically changed the way software applications are architected, designed and implemented. SOA allows developers to structure their systems as a set of ready-made, reusable and compostable services. The leading technology used today for implementing SOA is Web Services. Indeed, like all software, Web services are prone to change constantly to add new user requirements or to adapt to environment changes. Poorly planned changes may risk introducing antipatterns into the system. Consequently, this may ultimately leads to a degradation of software quality, evident by poor quality of service (QoS). In this paper, we introduce an automated approach to detect Web service antipatterns using genetic programming. Our approach consists of using knowledge from real-world examples of Web service antipatterns to generate detection rules based on combinations of metrics and threshold values. We evaluate our approach on a benchmark of 310 Web services and a variety of five types of Web service antipatterns. The statistical analysis of the obtained results provides evidence that our approach is efficient to detect most of the existing antipatterns with a score of 85% of precision and 87% of recall.

Software systems nowadays are complex and difficult to maintain due to continuous changes and bad design choices. To handle the complexity of systems, software products are, in general, decomposed in terms of packages/modules containing classes that are dependent. However, it is challenging to automatically remodularize systems to improve their maintainability. The majority of existing remodularization work mainly satisfy one objective which is improving the structure of packages by optimizing coupling and cohesion. In addition, most of existing studies are limited to only few operation types such as move class and split packages. Many other objectives, such as the design semantics, reducing the number of changes and maximizing the consistency with development change history, are important to improve the quality of the software by remodularizing it. In this article, we propose a novel many-objective search-based approach using NSGA-III. The process aims at finding the optimal remodularization solutions that improve the structure of packages, minimize the number of changes, preserve semantics coherence, and reuse the history of changes. We evaluate the efficiency of our approach using four different open-source systems and one automotive industry project, provided by our industrial partner, through a quantitative and qualitative study conducted with software engineers.

We propose in this paper to consider code-smells detection as a distributed optimization problem. The idea is that different methods are combined in parallel during the optimization process to find a consensus regarding the detection of code-smells. To this end, we used Parallel Evolutionary algorithms (P-EA) where many evolutionary algorithms with different adaptations (fitness functions, solution representations, and change operators) are executed, in a parallel cooperative manner, to solve a common goal which is the detection of code-smells. An empirical evaluation to compare the implementation of our cooperative P-EA approach with random search, two single population-based approaches and two code-smells detection techniques that are not based on meta-heuristics search. The statistical analysis of the obtained results provides evidence to support the claim that cooperative P-EA is more efficient and effective than state of the art detection approaches based on a benchmark of nine large open source systems where more than 85 percent of precision and recall scores are obtained on a variety of eight different types of code-smells.

One of the widely used techniques for evolving software systems is refactoring, a maintenance activity that improves design structure while preserving the external behavior. Exploring past maintenance and development history can be an effective way of finding refactoring opportunities. Code elements which undergo changes in the past, at approximately the same time, bear a good probability for being semantically related. Moreover, these elements that experienced a huge number of refactoring in the past have a good chance for refactoring in the future. In addition, the development history can be used to propose new refactoring solutions in similar contexts. In this paper, we propose a multi-objective optimization-based approach to find the best sequence of refactorings that minimizes the number of bad-smells, and maximizes the use of development history and semantic coherence. To this end, we use the non-dominated sorting genetic algorithm (NSGA-II) to find the best trade-off between these three objectives. We report the results of our experiments using different large open source projects.

Refactoring restructures a program to improve its structure without altering its behavior. However, it is challenging to preserve the domain semantics of a program when refactoring is decided/implemented automatically. Indeed, a program could be syntactically correct, have the right behavior, but model incorrectly the domain semantics. In this paper, we propose a multi-objective optimization approach to find the best sequence of refactorings that maximizes quality improvements (program structure) and minimizes semantic errors. To this end, we use the non-dominated sorting genetic algorithm (NSGA-II) to find the best compromise between these two conflicting objectives. We report the results of our experiments on different open source projects.

Detecting and fixing defects make programs easier to understand by developers. We propose an automated approach for the detection and correction of various types of design defects in source code. Our approach allows to automatically find detection rules, thus relieving the designer from doing so manually. Rules are defined as combinations of metrics/thresholds that better conform to known instances of design defects (defect examples). The correction solutions, a combination of refactoring operations, should minimize, as much as possible, the number of defects detected using the detection rules. In our setting, we use genetic programming for rule extraction. For the correction step, we use genetic algorithm. We evaluate our approach by finding and fixing potential defects in four open-source systems. For all these systems, we found, in average, more than 80% of known defects, a better result when compared to a state-of-the-art approach, where the detection rules are manually or semi-automatically specified. The proposed corrections fix, in average, more than 78%of detected defects.