An empirical study on the impact of refactoring activities on evolving client-used APIs

Abstract

Context: Refactoring is recognized as an effective practice to maintain evolving software systems. For software libraries, we study how library developers refactor their Application Programming Interfaces (APIs), especially when it impacts client users by breaking an API of the library. Objective: Our work aims to understand how clients that use a library API are affected by refactoring activities. We target popular libraries that potentially impact more library client users. Method: We distinguish between library APIs based on their client-usage (refereed to as client-used APIs) in order to understand the extent to which API breakages relate to refactorings. Our tool-based approach allows for a large-scale study across eight libraries (i.e., totaling 183 consecutive versions) with around 900 clients projects. Results: We find that library maintainers are less likely to break client-used API classes. Quantitatively, we find that refactoring activities break less than 37% of all client-used APIs. In a more qualitative analysis, we show two documented cases of where non-refactoring API breaking changes are motivated by other maintenance issues (i.e., bug fix and new features) and involve more complex refactoring operations. Conclusion: Using our automated approach, we find that library developers are less likely to break APIs and tend to break client-used APIs when addressing these maintenance issues.

Breaking bad? Semantic versioning and impact of breaking changes in Maven Central

“…Consequently, APIs-being software themselves-undergo continual and progressive change over time. The motivation behind this evolution is to provide more value to users by patching security issues, adding new features, simplifying the current API, fixing bugs, and improving maintainability [13,28].…”

Refactoring for software maintenance: A Review of the literature

“…They have noticed the following points: (a) the maintainers of the library have lower likelihood of breaking the client-used APIs in comparison with other library classes, (b) the found refactoring processed breaks only < 37% of the client-utilized APIs, (c) the remaining (63%) breakages of the API are triggered with the issues of the maintenance which will be possibly involving more complicated refactoring processes. (d) Simple refactoring processes (such as rename approach, move approach, and move field) have been applied less often to the client-used classes of the APIs, in comparison with other class types [32]. In the same year, Mohan explores a Search-based software maintenance (SBSM), develops and proposes a new tool for fully automated Java software maintenance with the use of the multi-objective, monoobjective, and many-objective methods of the searching.…”

Präzi: From Package-based to Call-based Dependency Networks

“…Datasets such as fine-GRAPE (Sawant and Bacchelli 2017) provide researchers with information on API usage for understanding the evolution and impact of deprecation (Robbes et al 2012;Sawant et al 2018b) and refactoring (Kula et al 2018) decisions in libraries. As demonstrated in (Robbes et al 2012)'s API deprecation analysis of the Smalltalk ecosystem, the absence of sequences or chains of API calls in such datasets limits the scope of additional confounding variables influencing the decision-making of APIs.…”