Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify. Consequently, it is often assumed that refactoring makes the code less prone to bugs. However, in practice, refactoring is a complex task and applied in different ways (e.g., various refactoring types, single vs. composite refactorings) and with a variety of purposes (e.g., root-canal vs. floss refactoring). Therefore, certain refactorings can inadvertently make the code more prone to bugs. Unfortunately, there is limited research in the literature on the long-term relationship between the different characteristics of refactorings and bugs. This paper presents a longitudinal study of 12 open source software projects, where 27,450 refactorings, 6,051 reported bugs, and 49,250 bugs detected with static analysis tools were analyzed. While our study confirms the common intuition that refactored code is less bug-prone than non-refactored code, we also extend or contradict existing body of knowledge in other ways. First, a code element that undergoes multiple refactorings is not less bug-prone than an element that undergoes a single refactoring. A single refactoring is the one not performed in conjunction with other refactorings in the same commit. Second, single refactorings often induce the occurrence of bugs across all analyzed projects. Third, code elements affected by refactorings made in conjunction with other non-refactoring changes in the same commit (i.e., floss refactorings) are often bug-prone. Finally, many of such bugs induced by refactoring cannot be revealed with state-of-the-art techniques for detecting behavior-preserving refactorings.

Refactoring is a practice widely adopted during software maintenance and evolution. Due to its importance, there is extensive work on the effectiveness of refactoring in achieving code quality. However, developer’s intentions are usually overlooked. A more recent area of study involves the concept of self-affirmed refactoring (SAR), where developers explicitly state their intent to refactor. While studies on SAR have made valuable contributions, they provide little insights into refactoring complexity and effectiveness, as well as the refactorings’ relations to specific non-functional requirements. A study by Soares et al. published in 2020 addressed such aspects, but it relied on a quite small sample of studied subject systems and refactoring instances (in addition to other limitations). Following the empirical method of replication, we expanded the scope of Soares et al.’s study by doubling the number of projects analyzed (eight in total), and a significantly larger set of validated refactorings (8,408). Our findings only partially align with the original study. We observed that when developers explicitly state their refactoring intent, the resulting changes typically involve a combination of different refactoring types, making them more complex. Additionally, we confirmed that such complex refactorings positively impact code’s internal quality attributes. Yet, while refactorings targeting non-functional requirements generally enhance code quality compared to refactorings without this explicit concern, our observations only partially confirm the original study’s conclusions. Furthermore, our results contradict the original study in various aspects. For example, we interestingly found that SARs (compared to non-SARs) tend to produce fewer negative effects on internal quality attributes despite their quite frequent complexity. These findings highlight the need for reducing the complexity of refactorings while maximizing their positive effects. They also underscore the importance of explicitly stating refactoring intentions, as this provides a clear mental framework that guides effective refactoring efforts.

Software modernization is a common activity in software engineering, since technologies advance, requirements change, and business models evolve. Differently from conventional software evolution (e.g., adding new features, enhancing performance, or adapting to new requirements), software modernization involves re-engineering entire legacy systems (e.g., changing the technology stack, migrating to a new architecture style, or programming paradigms). Given the pervasive nature of software today, modernizing legacy systems is paramount to provide customers with competitive and innovative products and services, while keeping companies profitable. Despite the prevalent discussion of software modernization in gray literature, and the many papers in the literature, there is no work presenting a “big picture” of contemporary software modernization, describing challenges, and providing a well-defined research agenda. The goal of this work is to describe the state of the art in software modernization in the past 10 years. We collect the state of the art by performing a rapid review (searching five digital libraries), identifying potential 3,460 studies, leading to a final set of 126. We analyzed these studies to understand which strategies are employed, the driving forces that lead organizations to modernize their systems, and the challenges that need to be addressed. The results show that studies in the last 10 years have explored eight strategies for modernizing legacy systems, namely cloudification, architecture redesign, moving to a new programming language, targeting reuse optimization, software modernization for new hardware integration, practices to leverage automation, database modernization, and digital transformation. Modernization is triggered by 14 driving forces, with the most common ones being reducing operational costs, improving performance and scalability, and reducing complexity. In addition, based on the analysis of existing literature, we present a detailed discussion of research opportunities in this field. The main challenges are providing tooling support, followed by defining a modernization process and considering better evaluation metrics. The main contribution of our work is to equip practitioners and researchers with knowledge of the current state of contemporary software modernization so that they are aware of practices and challenges to be addressed when deciding to modernize legacy systems.