-Improving a software system's internal structure through regular refactoring is considered vital for its long and healthy life. However, despite its amenities, refactoring is not readily adopted by software development teams in industry mainly due to strict project deadlines and limited resources. Hence, they look for optimal refactoring recommendations that would incur minimal effort overhead while outputting decent benefits in terms of enhanced software quality. To this end, we propose an approach for identifying and prioritizing objectoriented software classes in need of refactoring. Our approach first identifies the most refactoring-prone as well as architecturally relevant classes, and then generates class ranks based on the code smell information. In addition to locating classes with the most significant incremental refactoring opportunities, this work contributes through suggesting developers on estimating maximum code smell correction (paying off maximum technical debt) with minimum refactoring effort. We evaluated the proposed approach on a sample of 1621 classes and 2358 code smell instances, distributed over 28 versions of four open source java systems.
Maintenance and evolution are lifelines for the success of a
product in modern day software development. Evolving
software requires its design and code to be optimized
periodically in order to avoid any technical debt resulting from
decaying of such artifacts [
However, the ground reality is somewhat different. Not
only are the developers expected to regularly enhance the
quality of software, they are also under a constant pressure to
spend most of their person hours adding new features rather
than refactoring the source code [
This work looks for a solution in the Law of the Vital Few,
which states - “only 20% of code contains 80% of errors” [
Palomba et al. [
Tsantalis et al. [
There is limited research work performed in the area
pertaining to the prioritization of classes in need of urgent
refactoring treatments. Zhao et al.[
We follow the hypothesis stated by Girba et al. [
Another major factor that should be considered when
identifying candidates for refactoring is the extent to which
they are harmful to the system’s architectural design.
Architectural problems have more detrimental impact on the
quality and lifecycle of the system than other traditional code
smells. Therefore, we select those classes that contain code
smells having a direct relationship with such architectural
problems [
The data from the above two steps are combined and the common set of classes, which are both architecturally relevant as well as frequently refactored, are provided as input to the third step. The rest of the classes are discarded.
The resulting crucial and refactoring-prone classes are then
ordered according to their impact on the system’s quality. The
classes are ranked using class scores generated as follows:
Class Score = F ×S× ∑ (S(xi) × I(xi))
(1)
Here, F is the frequency score of a class. Every time a class is
found to be refactored at least once when comparing two
subsequent software versions, its frequency score is
incremented by 1. S is the severity score of a class. It measures
the negative impact of a class on the quality attributes of the
system. It is measured by exploiting several software metrics
like size, cohesion, coupling, complexity, etc. [
Once the class scores are generated, all these classes are ranked in decreasing order of their scores. Hence larger the Class Score value, higher the rank of the class; signifying the need of refactoring for a class. A threshold value can be associated with the class ranks to leave out the lowest ranked classes present in the sorted list, thus further reducing the number of shortlisted classes.
An example for the proposed approach and additional information regarding this work is publicly available1.
We chose four open-source Java applications to perform our experiments. Table I provides the descriptive characteristics (number of classes, Kilo Lines Of Code (KLOC), and number of code smell instances) of the selected systems, namely HealthWatcher2, orDrumbox3, GanttProject4 (Gantt for short) and JHotdraw5.
The overall research methodology followed is shown in
Fig. 2. The first step of the proposed approach involves
analyzing different stable versions of a given input system. The
classes (belonging to each current version), which have been
refactored at least once in previous software versions, are
recorded alongwith their frequency score values. For
identifying the number of frequently refactored classes in each
software system, Ref-Finder tool [
In the final step, JSpIRIT 7 is used to detect code smell instances in the current versions of the sample applications. Although JSpIRIT is generally used for prioritizing code smells, we exploited its detection features only (as it does not provide the code smell severity scores as desired for this study). It supports the identification of 10 code smells using a software metric-based detection strategy. This metric-based strategy dissolves our need to calculate the object-oriented metrics values separately for predicting smelly classes, as the classes will be automatically categorized as ‘smelly’ according to the presence of code anomalies. Thereafter, inFusion8 tool is used to calculate the severity index of classes and code smell instances. It supports the identification of 7 of the 10 code smells detected by JSpIRIT. Hence, we use only these 7 code smells1 in this work.
We utilize the approach evaluation parameters: Code smells
Correction Ratio (CCR) [
EE is defined as the total number of classes that needs to be refactored divided by the total number of classes present in the software. After calculating the total estimated effort for refactoring, the total reduction in refactoring effort can be deduced. EE is given by (3). (2) (3)
The evolution of sample applications is quantified with the help of three version specific characteristics mentioned in Table I. The percentage of refactored classes between any two subsequent versions is always greater than 0% across all applications, which is quite normal for real world software systems. On average, 30% of the total number of classes is architecturally relevant across all four sample applications. This indicates that 30% (avg.) of the classes stand critical to the respective architectures of the current versions of these applications, and hence need immediate refactoring. Further, it is inferred that, on average, out of those 30% classes, 21% classes are refactored more than once in the previous versions. Thus, these 21% classes are chosen as the most significant and refactoring-prone classes.
Table II highlights three top ranked classes for each application, respectively. Note that in this table, the two 541 596 584 601 623 599 641 653 668 1003 855 947 986 1172 1172 penultimate columns are devoted to the total number of code smell instances in a class and average of code smells severity values, respectively. However, for the actual calculation of the class scores (when exercising the proposed approach), we considered the individual code smells alongwith their respective severity scores. It is conspicuous from Table II that the four class score parameters (Section III.C) contribute uniformly in generating balanced ranks for the classes. E.g. for orDrumbox, class ControlerProduct has higher severity score than classes OrTrack, Song, and Command; but due to low average number of code smell instances and frequency score, it records a low class score (and rank). Moreover, it is found that the classes having higher frequency scores have a higher number of code smell instances too. Thus it is revealed that despite of having been refactored in the earlier versions, such classes are still smelly and need further attention.
The evaluation results are summarized in Table III. On average, nearly 40% (EE) of the total number of classes needs frequent refactoring treatments. At the same time, the CCR scores indicate that more than 75% of the code defects fall within these 40% classes. On applying refactoring treatments to these classes, a significant improvement in software quality is ensured as indicated by high CCR scores. At the next step (AC), we observed that almost half of the previously refactored classes do not pose any threat to the architectural degradation of the selected systems. For instance, for JHotdraw, 158 of 278 classes (56%) are architecturally relevant. Consequently, EE score for JHotDraw dropped to 20% with a minimal decline in CCR score. Similar results are obtained for orDrumbox; a refactoring effort of 26% and smell correction of 73%. We gathered the results for those classes having ranks above a custom threshold value of 20. The developers can choose any threshold values that help them establish the desired balance between the amount of smell correction and estimated refactoring effort for their projects.
The results revealed that the search space for refactoring opportunities (number of classes) is constantly shrinking with
Step AV AC GR AV AC GR AV AC GR AV AC GR each step of the proposed approach. We observed that on average (across all sample applications) the refactoring effort required to remove 65% (avg. CCR) of code smells comes out to be 16% (avg. EE); hence saving an estimated refactoring effort up to 84%. For HealthWatcher, EE value shows a similar trend whereas its CCR value is slightly less as compared to that for other applications; but still acceptable. Overall results indicate that a major chunk of code anomalies could be targeted with a significant reduction in refactoring effort. This approach provides the developers with an option to choose any number of top ranked classes to refactor depending upon an affordable balance between the code smell corrections and estimated refactoring effort.
A construct validity threat concerns the possible errors (like some classes may be missed or may be identified as false positives) while identifying the refactored classes, architecturally relevant classes and code smell instances. To mitigate this threat, we considered widely known and fairly accurate code smell detection and refactoring detection tools that have been used in the relevant literature. While analyzing the software versions, we considered all those classes that have been refactored more than once. It would also include such classes that underwent a change just once during their evolution across various software versions. To mitigate this threat, we manually analyzed the classes, and decided whether they should be included or not. We analyzed four small and medium-sized open source java systems. This could affect the generalization of our approach when applied to large-sized commercial systems as well as systems written in other programming languages. However, the variable-sized sample applications along with the consistency in the experimental results across those applications minimize this threat to some extent.
In this study, we presented an approach for the prioritization of classes in need of refactoring. The proposed approach combines three different perspectives, i.e. historical data, architectural design, and severity of the class; and generates a prioritized list of classes. By prioritizing the classes based on our approach, up to 84% of refactoring effort was expected to be saved while also eradicating 65% (approx.) of the code smells for the four selected software applications. The proposed approach and the related findings can be useful for the development teams, which are short on project time and budget, to have refactoring processes on board. Also, such a prioritization of refactoring opportunities might help the developers in doing away with having to process large sets of refactoring recommendations.
We intend to extend this work in a number of ways. Since our initial experimental study includes small and medium-sized projects, we plan to replicate our experiments to the large-sized systems and industrial projects in future. An important future work would be to aim more number of distinct code smells to further gain in terms of saved refactoring effort and increased code smell correction. We also aim to compare our results with previous class prioritization techniques targeting refactoring. Lastly, we intend to implement our approach in the form of an automated tool that provides a prioritized list of classes in need of refactoring, and let the developers opt for the right balance between the estimated refactoring effort savings and expected code smell corrections.