Why Developers Refactor Source Code

Pantiuchina, Jevgenija; Zampetti, Fiorella; Scalabrino, Simone; Piantadosi, Valentina; Oliveto, Rocco; Bavota, Gabriele; Penta, Massimiliano Di

doi:10.1145/3408302

Cited by 47 publications

(38 citation statements)

References 73 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, we reinforce findings from a recent study that point out a significant rate of multiple extractions to decompose methods in a single commit [49]. Also, we extend the viewpoint of the study that investigated the reasons behind refactoring tasks [30,34,35,41].…”

Section: Related Worksupporting

confidence: 84%

“…To assess the motivations, we look for a sample from commits confirming the changes and also describing the central reasons. The rationale of this research question is to complement studies on refactoring motivations that consider different perspectives [15,30,34,35]. Moreover, we intend to improve future versions of the proposed catalog, for example, including real examples and discussions regard the applicability in practical scenarios.…”

Section: Inline Methodsmentioning

confidence: 99%

“…Overall, the reasons are centered on four main common software tasks: Code Design, Tests, Features, and Bugs [30,34].…”

Section: (Rq3) Why Do Developers Apply Composite Refactorings?mentioning

confidence: 99%

“…Refactoring was already studied scenarios such as code review [19,25,38,39], code understanding [30,34,40,41], and education [42,43]. However, these studies do not propose catalogs of refactorings operations to improve software practices.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

Towards a Catalog of Composite Refactorings

Brito¹,

Hora²,

Valente³

2022

Preprint

View full text Add to dashboard Cite

Catalogs of refactoring have key importance in software maintenance and evolution, since developers rely on such documents to understand and perform refactoring operations. Furthermore, these catalogs constitute a reference guide for communication between practitioners since they standardize a common refactoring vocabulary. Fowler's seminal book on refactoring describes the most popular catalog of refactorings, which documents single and well-known refactoring operations. However, sometimes refactorings are composite transformations, i.e., a sequence of refactorings performed over a given program element. For example, a sequence of Extract Method operations (a single refactoring) can be performed over the same method, in one or in multiple commits, to simplify its implementation, therefore, leading to a Method Decomposition operation (a composite refactoring). In this paper, we propose and document a catalog with six composite refactorings. We also extend a refactoring detection tool to identify such composite refactoring in commits histories. We rely on our tool extension to mine composite refactorings in ten well-known open source projects and characterize the detected composite refactorings, under dimensions such as size and location. Finally, we qualitatively study the descriptions of commits including composite refactorings to shed preliminary light on the motivations behind such operations. We conclude by addressing the applications and implications of the proposed catalog.

show abstract

Section: Related Worksupporting

confidence: 84%

Section: Inline Methodsmentioning

confidence: 99%

“…Overall, the reasons are centered on four main common software tasks: Code Design, Tests, Features, and Bugs [30,34].…”

Section: (Rq3) Why Do Developers Apply Composite Refactorings?mentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Towards a Catalog of Composite Refactorings

Brito¹,

Hora²,

Valente³

2022

Preprint

View full text Add to dashboard Cite

show abstract

“…There are many studies [5], [6], [20], [30], [31] based on data mining and static analysis of the npm ecosystem. A study by Zimmermann et al [5], based on the analysis of the packages' dependencies in the npm registry, shows that the npm ecosystem faces single-point-of-failure risks, as problems in individual packages may impair large parts of the entire ecosystem.…”

Section: Related Workmentioning

confidence: 99%

Automatically Assessing and Extending Code Coverage for NPM Packages

Sun

Rosà

Bonetta³

et al. 2021

2021 IEEE/ACM International Conference on Automation of Software Test (AST)

View full text Add to dashboard Cite

Typical Node.js applications extensively rely on packages hosted in the npm registry. As such packages may be used by thousands of other packages or applications, it is important to assess their code coverage. Moreover, increasing code coverage may help detect previously unknown issues. In this paper, we introduce TESA, a new tool that automatically assembles a test suite for any package in the npm registry. The test suite includes 1) tests written for the target package and usually hosted in its development repository, and 2) tests selected from dependent packages. The former tests allow assessing the code coverage of the target package, while the latter ones can increase code coverage by exploiting third-party tests that also exercise code in the target package. We use TESA to assess the code coverage of 500 popular npm packages. Then, we demonstrate that TESA can significantly increase code coverage by including tests from dependent packages. Finally, we show that the test suites assembled by TESA increase the effectiveness of existing dynamic program analyses to identify performance issues that are not detectable when only executing the developer's tests.

show abstract

Behind the scenes: On the relationship between developer experience and refactoring

AlOmar

Peruma

Mkaouer

et al. 2021

J Software Evolu Process

View full text Add to dashboard Cite

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.

show abstract

Why Developers Refactor Source Code

Cited by 47 publications

References 73 publications

Towards a Catalog of Composite Refactorings

Towards a Catalog of Composite Refactorings

Automatically Assessing and Extending Code Coverage for NPM Packages

Behind the scenes: On the relationship between developer experience and refactoring

Contact Info

Product

Resources

About