Does shortening the release cycle affect refactoring activities: A case study of the JDT Core, Platform SWT, and UI projects
Introduction
Refactoring in software systems has been investigated extensively throughout the years. Multiple aspects such as the impacts on code quality [1] and testing activities [2] have been investigated in order to determine how important it is to refactor the code in a software development project. Past studies [3], [4], [5] have concluded that refactoring is beneficial to a software development project and that it is worth dedicating some development time to refactor the code.
Modern-day software companies, however, have started changing the way they develop software systems. Over the past few years, large companies such as Google, Facebook, Firefox, and Netflix have all decided to adopt a short release cycle model for various reasons such as keeping up with customer expectations or keeping up with competitors [6].
This short release cycle model has been referred to as rapid releases (RR), or short releases (SR), and the old yearly release model as traditional releases (TR). Several studies have been conducted in order to better understand the impacts of shorter releases by comparing various metrics and activities before and after shortening the release cycles. For example, a previous study [2] showed that shorter releases’ builds contain more code commits than traditional releases’ builds. Another study [1] also found that short release cycles had a significant impact on the number of files being affected per commit. The code quality, number of bugs, integration, and testing in shorter releases have also all been subject to investigation in past studies [1], [2], [7] but to the best of our knowledge, the impacts of shortening the release cycles on refactoring activities have not yet been investigated. In this study, we therefore aim to further contribute to the empirical knowledge related to the impacts of shortening the release cycles on software development activities.
In this case study, we investigate if shortening the release cycles had any impacts on refactoring activities in three software development projects. Due to the possible negative impacts of not refactoring, it is important for potential short release adopters to be aware of the possible downsides related to refactoring activities that shorter releases can bring to a project. We examine four aspects of refactoring activities: the amount of refactoring done, the efforts devoted to refactoring, the type of refactoring applied in the code, and the human resources dedicated to refactoring. These aspects allow us to draw an overall picture of refactoring during short releases and traditional releases in order to determine if the refactoring activities are impacted after adopting a shorter release cycle.
Paper Organization: Section 2 introduces previous studies involving refactoring and short releases. Section 3 describes our dataset selection, its extraction and the filtering process, and Section 4 presents our results. In Section 5, we summarize our findings, discuss their implications and address some of the threats to the validity of this study. We conclude in Section 6 where we briefly summarize our findings and make our final comments on refactoring and short releases.
Section snippets
Refactoring
Refactoring has been widely defined as changes that improve code quality but preserve the software system’s external behavior [8]. Thanks to the improvement of refactoring detection algorithms [9], [10], [11], [12], [13] that automatically identify refactoring activities from source code histories, many researchers have conducted empirical studies [3], [14], [15], [16], [17], [18], [19] on software evolution and software refactoring.
Refactoring and Software Quality. In a previous study [20],
Study design
This section explains the design of our case study in order to address our research questions introduced in Section 3.1. To measure the impacts of switching to a shorter release cycle on refactoring activities, we compare two datasets derived from traditional yearly releases and shorter quarterly releases. Fig. 1 depicts an overview of the data extraction process. We first apply a refactoring analysis tool to each revision in code repositories. Next, we measure the relevant metrics and merge
(RQ1) do developers still refactor as much?
Motivation. Due to the shorter releases, developers do not have as much time to dedicate to tasks not related to feature development and maintenance such as testing [39], [40], [41], [42] or refactoring. For example, Vassallo et al. [38] found that lack of time is the main barrier to refactoring while investigating continuous refactoring in CI. We therefore investigate if adopting shorter release cycles affects the overall project’s refactoring activity by comparing how much refactoring was
Evolution of refactoring activities
Intuitively, it would make sense if refactoring activities diminish over time as a project ages and becomes more mature. If that was the case, then it would be less likely that the impacts observed in RQ1 and subsequent RQs would be consequences of shortening the release cycle. To verify this hypothesis, we plotted the evolution of refactoring activities since the first named version (3.2) in 2006. From Fig. 4, we notice that the jdt.core seems to already have been on a downward trend of
Conclusion
In this study, we investigated the impacts of shortening the release cycles on refactoring activities in three Eclipse projects which all developed using both traditional yearly releases and shorter quarterly cycles. Through this case study, we found that shortening the release cycles may impact the refactoring activities of a software project in various ways. We also found that some of the refactoring patterns that were less common after shortening the releases are usually applied to improve
CRediT authorship contribution statement
Olivier Nourry: Methodology, Software, Validity, Formal analysis, Investigation, Writing. Yutaro Kashiwa: Conceptualization, Data curation, Visualization. Yasutaka Kamei: Supervision, Project administration. Naoyasu Ubayashi: Funding acquisition.
Declaration of Competing Interest
Japan Society for the Promotion of Science (International Joint Research Program with SNSF (Project “SENSOR”), Japan Society for the Promotion of Science (JP18H03222).
References (60)
- et al.
A large-scale empirical exploration on refactoring activities in open source software projects
Sci. Comput. Program.
(2019) - et al.
Code smells and refactoring: A tertiary systematic review of challenges and observations
J. Syst. Softw.
(2020) - et al.
A systematic and comprehensive investigation of methods to build and evaluate fault prediction models
J. Syst. Softw.
(2010) - et al.
Is lines of code a good measure of effort in effort-aware models?
Inf. Softw. Technol.
(2013) - et al.
Understanding the impact of rapid releases on software quality
Empir. Softw. Eng.
(2015) - et al.
On rapid releases and software testing: A case study and a semi-systematic literature review
Empir. Softw. Eng.
(2015) - F. Palomba, A. Zaidman, R. Oliveto, A. De Lucia, An exploratory study on the relationship between changes and...
- M. Kim, D. Cai, S. Kim, An empirical investigation into the role of api-level refactorings during software evolution,...
- K. Stroggylos, D. Spinellis, Refactoring–does it improve software quality? in: Proceedings of the 5th International...
- et al.
Frequent releases in open source software: A systematic review
Information
(2017)