Evaluating the Impact of Refactoring Techniques Order

On Code Maintainability
: A Case Study
Muhammad Imran L165059
Abstract: - Software code refactoring is used to remove their study. Some of them acknowledged that
bad smells and improve code quality. Bad smells are changing the order of refactoring techniques
alarming for long term execution of the code. There is a lot
of research on refactoring techniques. Many studies have
how they are applied will affect the quality of
been conducted on evaluation of impact of refactoring the code in positive sense. While others have
techniques have proved that refactoring enhances the code proved that reordering doesn’t improve the code
quality in many aspects. But no remarkable work is found design quality. So we established a hypothesis
on impact of refactoring techniques sequence that change that order of refactoring techniques will improve
the code quality when same refactoring techniques are
applied in different order. A few researchers conducted the code quality.
their study on impact of sequence of refactoring techniques To prove the established, we conducted a case
but that does not provide some tangible solution or study. We selected a project (HKBApp) to
guideline. In this study, a few experiments are conducted evaluate the impact of refactoring techniques
on a real life java project. Selected project is identified with
some code smells. As a remedy, two refactoring techniques
orders. HKBApp is software written in java to
are organized in different sequences. In each experiment, extract specific data from Oracle for SAP
one sequence is applied and changes in software metrics upload. The software is composed of several
are noted. Similarly refactoring techniques are applied on classes.
project in all sequences. Finally, results are compared as Section II discusses the related work done before
per changes and some suggestion is provided for
implementation of refactoring techniques in certain order on the impact of order of refactoring techniques.
Some of the studies are discussed. What is
I. INTRODUCTION proved in it and criticism on it. Section III is
problem statement. In this section we will
Code refactoring is the process of discussed the purpose of this study in depth.
restructuring existing software code. Changing Section IV is about the Research methodology
the code in a way that it doesn’t affect the discussed in details. Section V discusses the
behavior of the program. There are number of Experiment Setup in details. The experiment
principles or rules to apply refactoring model and project being used etc. Section VI
techniques in order to remove code smells from discusses the results of the study and suggestion
the code. According to Martin Fowler, "a code about usage of refactoring techniques in certain
smell is a surface indication that usually order. Section VII discusses what we concluded
corresponds to a deeper problem in the system. from study and finally, Future work is stated in
A Bad smell is a certain structure in the code section VIII. References are given in Section 9.
that does not fulfill design principles [1]. A
software bug usually causes failure during the II. RELATED WORK
execution of a program. Bad smells are working
code that cause no bugs and yield their expected Even though very few are there who consider
output. However, they indicate a potential the order of refactoring techniques while
problem in the code that could cause bugs; they applying on code to remove bad smells. But still
also make the code less maintainable. Martin there is a plenty of work available to review and
Fowler has identified 22 code smells [2]. When study the work done. In our case, a very
many bad smells occur in the software, many renowned study conducted by Yahya Khrishe
refactoring techniques can be applied to address and Mohammad Alshayeb addressed the topic in
these smells. a very concise way [3]. Worthy researchers have
Researchers have addressed the impact of put the idea for evaluation of order of
ordering of refactoring techniques on code in
refactoring techniques by conducting some quality smells are certain structures in the code
experiment on sample code. that indicate violation of fundamental design
The most renowned work for this study is the principles and negatively impact design quality.
study by Liu et al. [4, 5]. They observe the Code smells are not but rather they are not
relationship between bad smells and the effect of technically incorrect and do not currently
possible sequences of refactoring. However, the prevent the program from functioning. Instead,
objective of this paper is to empirically evaluate they indicate weaknesses in design that may be
whether the order of applying refactoring slowing down development or increasing the
sequence affects the quality of the generated risk of bugs or failures in the future. Bad code
code using different software metrics for smells can be an indicator of factors that
evaluation. contribute to technical debt.
Meananeatra [6] proposed an approach to Code refactoring is the process of restructuring
identifying optimal refactoring sequence that existing source code without changing its
meets four criteria: 1) the number of removed behavior [7]. Refactoring improves
bad smells, 2) maintainability, 3) the size of nonfunctional attributes of the software.
refactoring sequence and 4) the number of Advantages include improved code readability
modified program elements. The main purpose and reduced complexity; it can improve source-
of their work was to help developers to identify code maintainability and create a more
the appropriate refactoring techniques and to expressive internal architecture or object model
select an optimal refactoring sequence based on to improve extensibility. Refactoring applies a
the developer objective. A prototype was series of standardized techniques, each of which
developed which accepts the objective and the is a tiny change in code that either preserves the
code as an input, the input undergoes a specific behavior of the program; Code refactoring may
process that will result in a several refactoring also resolve hidden, dormant, or undiscovered
sequences, a metric value is calculated for each computer bugs or vulnerabilities in the system
sequence, a graph that represents all possible by simplifying the underlying logic and
sequences is constructed and the sequence with eliminating unnecessary levels of complexity
the best value is chosen. [8]. If done poorly it may fail the requirement
Refactoring and evaluation of certain results are that external functionality not be changed,
addressed in concise way for the code quality. introduce new bugs.
So we established a hypothesis about the impact In our study, the addressable thing is evaluation
of reordering the refactoring techniques. of impact of refactoring if order or sequence of
H0 (Null Hypothesis) says that changing the refactoring techniques is changed while applying
sequence of techniques while applying on the it to the code.
code doesn’t yield different results. I.e. there is
no change in source code of software when same IV. RESEARCH METHODOLOGY
refactoring techniques are applied in different
orders. We selected a real life project obtained from a
HA (Alternate Hypothesis) states that changing retail business.
the sequence of same refactoring techniques HKBApp is software developed in Java to
changes the code structure and it impact the extract specific data in specific format from
software design and quality. Oracle DBMS for SAP upload. SAP upload is
configured to accept the extracted data from
Oracle through this application.
III. PROBLEM STATEMENT Project is composed of several classes
responsible for the functionality it is written for.
Code smell, also known as bad smell, in We performed our experiments on the classes
computer programming code, refers to any that contains bad smells in it.
symptom in the source code of a program that This experiment is consisted of few many things
possibly indicates a deeper problem. The way to including HKBApp Source code for experiment,
look at smells is with respect to principles and Eclipse IDE, Jdeodorant plugin for code smell
identification, JHAWK (to measure the software
metrics) and software metrics. We applied
refactoring techniques in several orders on our
code and evaluated the result by JHawk software
metrics tool.

Average Cyclomatic complexity and

maintainability index are measures for code
maintainability [9]. Less Average Cyclomatic
complexity (CC) means more code
maintainability and more CC mean less code
maintainability. Software Maintainability Index
(MI) is a single-value indicator for the
maintainability of a software system. It was
proposed by Oman and Hagemeister in the early
nineties [10].
Since, we conducted this study to observe the
impact of order of refactoring techniques on
code maintainability. So Average Cyclomatic
complexity and maintainability index (MI) will
be standard to evaluate the results.
The pictorial view of the research methodology
is described in the Figure 1.
Start from the oval, we identified the code
smells. After identifying the code smells, we
applied refactoring techniques in six different
orders to remove corresponded code bad smells. Figure I: Flow chart for our Research
It yielded some results about change in software Methodology
metrics. We evaluated and noted the result and
then decide the next sequence for refactoring i. INDENTIFICATION OF BAD
techniques to be applied. In similar fashion, SMELLS
results for all applicable ordering of refactoring Code smells identified using JDeodorant in the
principles are evaluated. HKBSales.java and ABSales.java are God Class
and Duplicate Code. JDeodorant is installed and
configured in Eclipse Neon IDE (release 4.6.3).
After the configuration, the IDE provides a
menu for code smells identification on menu
bar. We selected two bad smells one by one and
run project analysis for each bad smell. We
noted the results of the code smell identification
and prepare a refactoring plan as remedy for
these code smells to apply in different
sequences.
ii. IMPLEMENTATION OF
REFACTORING TECHNIQUES
After the identification of the code smells, the
next step is to prepare sequences for two
refactoring techniques for the code smells found
in HKBSales.java and ABSales.java classes of
the project. There are different combinations of
two refactoring techniques. Techniques that Extraction Log file) repeats in every method for
were used to remove code smells from our java Data Extraction. Each time, new Object for file
class are Extract Class and Extract method. is created and log is written in the file. This is
repeated code throughout the class and that is a
iii. METRICS MEASUREMENT bad smell.
JHawk is a tool to measure software metrics for Refactoring techniques that are used in
java projects. It measures many software metrics experiments are
but since we are conducting this study in the 1. Extract Class: It is used when we have a class
context of code maintainability, so we that contains lots of functionality, it may reach
considered software metric i.e. maintainability to a point where the class is complex and hard to
index (MI) and Average Cyclomatic Complexity maintain. In this case, using extract class will
(Avg CC). separate the responsibilities by extracting part of
Code Smells identified in HKBApp are: the class to a sub class.
a. Large Class 2. Extract Method: It is used to make the code
Class HKBSales.java and ABSales.java are more readable and maintainable and avoid
explicitly large. It is consisted of much longer redundancy in code in case of using the same
functionality including connection to remote part of code multiple times. It is done by
database server and methods for Extraction of grouping part of the code into a method and
different type of data. Separate function for each choosing a suitable name for it, then replacing
type of Data Extract makes the class large. that part with a method call.
b. Duplicate Code Table I is representation for metrics used for
Classes contain some explicit duplicate code. evaluation are:
Code for a specific functionality (Write
Metrics Description
Lines of Code Number of Executable Line in source code
Average Cyclomatic It gives the notion of structural complexity of a method or source code. Lower is
Complexity better. A McCabe complexity under 5 is good, from 5-10 is OK, and over 10 is
too complex.
Maintainability Software Maintainability Index (MI) is a single-value indicator for the
Index(MI) maintainability of a software system. It was proposed by Oman and Hagemeister
in the early nineties. The Maintainability Index is computed by combining four
traditional metrics. It is a weighted composition of the average Halstead Volume
per module, the Cyclomatic Complexity, the number of lines of code (LOC) and
the comment ratio of the system.
Table I: Software Metrics used for Evaluation
When extract class is applied, a new class
V. EXPERIMENTAL SETUP HKBSalesProduct.java was extracted that is
Two different orders of refactoring techniques consisted of server connection functionality.
are: Duplication of code exists when log is written
a. Extract Class – Extract Method about the extracted data or connection to the
b. Extract method – Extract Class server is made. A File Object is created each
time after the code for data extraction logic in
Before applying any refactoring technique in each method. Duplicate Code is not extracted
any order, we run JHawk software metrics tool into new class rather refactoring is applied in the
on original project and noted the metrics for same class and to write log, method is called
original class. Then we applied refactoring in from class HKBSalesProduct.java by creating an
mentioned above sequence. object of HKBSales.java.
Sequence 1 is Extract Class – Extract method. Sequence2 (Extract method – Extract Class) was
HKBSales.java and ABSales.java are God performed in such a way that method for
Classes on which Extract Class can be applied. duplicate code was extracted before extracting
class. Applying refactoring techniques in such
 fashion changes the structure of the code that extracted class. Extract class calls mother class’s
impacts the software metrics. method for writing log.
Extracting method first doesn’t let the ‘Extract
Class’ to move duplicated code in newly

VI. RESULTS
During the practice, we noted the results for
software metrics measured by JHawk. Results
for each experiment are given in the Table II.
Software
Metric
HKBApp Original Sequence 1 Sequence2
HKBSales.java ABSales.java HKBSales.java ABSales.java HKBSales.java ABSales.java
Avg 7.55 7.60 5.53 5.08 5.47 5.08
Cyclomatic
Complexity
Lines of Code 1436 1305 1372 1222 1369 1221
Maintainability 116.72 113.09 50.11 45.38 50.56 45.38
index

Table II: Representation of Software metrics to test the code design

It can be observed that our java project doesn’t Lines of code in ABSales.java reduced from
depict good software measure before 1222 to 1221; Average cyclomatic complexity
implementation of any refactoring sequence. But and maintainability remained same for both
after implementation of refactoring techniques in refactoring orders.
different order, JHawk yielded different
software metric measure against each sequence. VII. CONCLUSION
After applying sequence 1(Extract Class – When there are bad smells in code, refactoring is
Extract Method) Line of Codes in recommended to make a flawless software
HKBSales.java reduced while average product. This may return different code
Cyclomatic complexity of the whole system structures after applying a sequence of different
reduced from 7.55 to 5.53 and Maintainability refactoring. We conducted a study to determine
Index increased from 114.65 to 130.50. whether applying refactoring in different order
As a result of Refactoring sequence 2 that is yields different results or not. We used two
Extract method then Extract Class, we analyzed refactoring techniques to conduct different
betterment in code. Avg Cyclomatic complexity experiments to test the impact of each sequence.
increased slightly but maintainability index The experiments include all possible sequencing
reduced from 116.72 to 50.11. Line of codes in options between the two different refactoring
ABSales.java reduced from 1305 to 1222; methods. After implementation of refactoring
Average cyclomatic complexity reduced from techniques, we concluded that changing the
7.60 to 5.08 and maintainability index reduced sequence of inter-related refactoring techniques
from 113.09 to 45.38. order doesn’t affect the code remarkably. Even
After applying the sequence 2 that is (Extract if, there are slight changes in our software
Method- Extract Class), following changes metrics against each refactoring sequence, but
occurred in our code. that is not as much influencing to be consider for
Lines of code in HKBSales.java reduced from better code design. So our Null hypothesis (H0)
1372 to 1369; Average Cyclomatic complexity proved true that if there are inter-related bad
reduced from 5.38 to 5.08 and maintainability smells in code, applying in different orders,
index increased from 50.11 to 50.56.
refactoring techniques doesn’t change the code Engineering, 2009, pp. 265-268.
maintainability. [5] H. Liu, Z. Ma, W. Shao, and Z. Niu,
VIII. THREATS TO VALIDITY "Schedule of Bad Smell
Even though the project selected for experiment Detection and Resolution: A New Way to Save
was commercially being used but not bigger Effort," in
enough to test the impact of refactoring IEEE transaction on software engineering, 2012,
techniques in different order with accuracy. pp. 220-235.
Only a few and common bad smells were [6] P. Meananeatra, "Identifying refactoring
identified and few software metrics were chosen sequences for improving software
to run experiment. More inter-related refactoring maintainability," in Proceedings of the 27th
techniques and bad smells can identified and IEEE/ACM International, 2012, pp. 406-409.
experiment can be evaluated using more [7] Emerson Murphy-Hill, How We Refactor,
software metrics like coupling between objects and How We Know It
and number of statements etc. [8] M. Fowler. Refactoring, improving the
IX. FUTURE WORK design of existing Code. Addison-Wesley
Our study was limited to just few code smells in Longman Publishing Co., Inc., Boston, MA,
code of a real life project but it is aimed to be USA, 1999
expanded to multiple code smells to evaluate [9] Ankita, An approach for improving the
the impact of Refactoring techniques Order on concept of Cyclomatic
software design. Complexity for Object-Oriented Programming
Identifying more inter-related refactoring [10] Oman, Paul, and Jack Hagemeister.
techniques and code smells and evaluation of it “Metrics for assessing a software system’s
on more big projects to evaluate the overall maintainability.” In Proc. Conference on
software’s design in the context of code Software Maintenance. IEEE, 1992.
maintainability.
Further, we’ll consider more software metrics
for other software design aspects like reusability
and stability.
REFERENCES
[1] G. Suryanarayana, G. Samarthyam, and T.
Sharma, Refactoring for Software Design
Smells: Managing Technical
Debt: Elsevier, 2014.
[2] Min Zhang1, Tracy Hall2 and Nathan
Baddoo, Code Bad Smells: a review of current
knowledge
[3] Yahya Khrishe, Mohammad Alshayeb, An
Empirical Study on the Effect of the Order of
Applying Software Refactoring, Information and
Computer Science Department
King Fahd University of Petroleum and
Minerals
Dhahran, 31261 Saudi Arabia
{g201306450, alshayeb}@kfupm.edu.sa
[4] H. Liu, L. Yang, Z.Niu, Z. Ma, and W. Shao,
"Facilitating software refactoring with
appropriate resolution order of bad smells," in
Proceedings of the 7th joint meeting of the
European software engineering conference and
the ACM SIGSOFT symposium on The
foundations of software