Refactoring is a process for improving the internal characteristics and design of software while preserving its external behaviour. Refactoring has been suggested as a positive influence on the long-term quality and maintainability of software and, as a result, we might expect benefits of a lower future change or fault propensity by refactoring software. Conversely, many studies show a correlation between change and future faults; so application of a refactoring may in itself increase future fault propensity, negating any benefit of the refactoring. In this paper, we determine whether the refactoring process reaps future maintenance benefits and, as a consequence, results in software with a lower propensity for both faults and change. We studied a large, commercial software system over a twelve-month period and identified a set of refactored classes during the middle four months of the study; a bespoke tool was used to detect occurrences of fifteen types of refactoring. We then examined the fault-and change-proneness of the same set of refactored classes in the four months prior to, during, and after the period of refactoring to determine if change or fault activity was reduced either during or after the period of refactoring studied. We also compared these trends with remaining classes in the system that had not been refactored over the same periods. Results revealed that refactored classes experienced a lower change-proneness in the period after refactoring and were significantly less fault-prone during and after the period of refactoring, even when accounting for the effects of change. The study therefore presents concrete evidence of the benefits of refactoring in these two senses.

No abstract

No abstract

P u b l i s h e d b y E T H Z u r i c h , C h a i r o f S o f t w a r e E n g i n e e r i n g © J o t , 2 0 1 0 O n l i n e a t h t t p : / / w w w . Abstract This paper documents a study of change in commercial, proprietary C# software and attempts to determine whether a relationship exists between class changes and faults and the design context of a class, namely its size and inheritance relationships.Results showed a strong positive correlation between the size of a class and change-proneness but not for all the class features studied. Classes within a specific range of a) inheritance depth and b) number of children were found to be relatively more prone to change. For the fault data and for the same class features, similar results were found. The most striking result to emerge however was the existence of an inheritance depth 'interval' between which change (and faultproneness) were at their highest. Below and above that interval, both features were less prominent. The results thus add weight to the claims of other previous studies which suggest that there is an optimal level of inheritance, beyond which maintenance may become problematic from both a change and fault perspective.

This paper documents a study of the application of refactorings in commercial C# software comprising 270 versions over a two-month period. The software was developed in a continuous integration environment in a large, multinational company where each software change committed to the source control was regarded as a new version. The aim of the research was to compare and contrast the results from two previous refactoring studies with those of the C# software. Method. A tool was developed to compare each version with the previous and detect occurrences of fifteen types of refactorings in both production and test classes. In total, over one thousand separate refactorings were identified. We then extended the profile of refactorings to compare (separately) the types of refactorings identified in test code and those in production code. Finally, we explored the interrelationships between a subset of the fifteen refactorings as a part explanation for the results. Conclusions. While 'simpler' refactorings were common, the more 'complex' structural refactorings were relatively rare. This supported the key result of an earlier empirical study by Advani et al. where Java open-source was used. Distinct differences were found in the types of refactoring applied to each code type. Support was found for a recent observation of Zaidman et al. in terms of parallel effort devoted to production and test classes. The study thus illustrates a strong commonality between refactoring trends found in both previous studies. Analysis of, and insight into all of our results were informed by follow-up discussions and consultation with the company's Architect.