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

V. EXPERIMENTAL SETUP
Two different orders of refactoring techniques
are:
a. Extract Class – Extract Method
b. Extract method – Extract Class
Before applying any refactoring technique in
any order, we run JHawk software metrics tool
on original project and noted the metrics for
original class. Then we applied refactoring in
mentioned above sequence.
Sequence 1 is Extract Class – Extract method.
HKBSales.java and ABSales.java are God
Classes on which Extract Class can be applied.
When extract class is applied, a new class
HKBSalesProduct.java was extracted that is
consisted of server connection functionality.
Duplication of code exists when log is written
about the extracted data or connection to the
server is made. A File Object is created each
time after the code for data extraction logic in
each method. Duplicate Code is not extracted
into new class rather refactoring is applied in the
same class and to write log, method is called
from class HKBSalesProduct.java by creating an
object of HKBSales.java.
Sequence2 (Extract method – Extract Class) was
performed in such a way that method for
duplicate code was extracted before extracting
class. Applying refactoring techniques in such
 fashion changes the structure of the code that
impacts the software metrics.
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
HKBSales.jav ABSales.java HKBSales.jav ABSales.java HKBSales.java ABSales.java
a a
Avg 7.55 7.60
Cyclomatic
Complexity
Lines of Code 1436 1305
Maintainabilit 116.72 113.09
y index
Table II: Representation of Software metrics to test the code design
It can be observed that our java project doesn’t
depict good software measure before
implementation of any refactoring sequence. But
after implementation of refactoring techniques
in different order, JHawk yielded different
software metric measure against each sequence.
After applying sequence 1(Extract Class –
Extract Method) Line of Codes in
HKBSales.java reduced while average
Cyclomatic complexity of the whole system
reduced from 7.55 to 5.53 and Maintainability
Index increased from 114.65 to 130.50.
As a result of Refactoring sequence 2 that is
Extract method then Extract Class, we analyzed
betterment in code. Avg Cyclomatic complexity
increased slightly but maintainability index
reduced from 116.72 to 50.11. Line of codes in
ABSales.java reduced from 1305 to 1222;
Average cyclomatic complexity reduced from
7.60 to 5.08 and maintainability index reduced
from 113.09 to 45.38.
After applying the sequence 2 that is (Extract
Method- Extract Class), following changes
occurred in our code.
Lines of code in HKBSales.java reduced from
1372 to 1369; Average Cyclomatic complexity
extracted class. Extract class calls mother class’s
method for writing log.
Sequence 1 Sequence2
5.53 5.08 5.47 5.08
1372 1222 1369 1221
50.11 45.38 50.56 45.38
reduced from 5.38 to 5.08 and maintainability
index increased from 50.11 to 50.56.
Lines of code in ABSales.java reduced from
1222 to 1221; Average cyclomatic complexity
and maintainability remained same for both
refactoring orders.
VII. CONCLUSION
When there are bad smells in code, refactoring is
recommended to make a flawless software
product. This may return different code
structures after applying a sequence of different
refactoring. We conducted a study to determine
whether applying refactoring in different order
yields different results or not. We used two
refactoring techniques to conduct different
experiments to test the impact of each sequence.
The experiments include all possible sequencing
options between the two different refactoring
methods. After implementation of refactoring
techniques, we concluded that changing the
sequence of inter-related refactoring techniques
order doesn’t affect the code remarkably. Even
if, there are slight changes in our software
metrics against each refactoring sequence, but
that is not as much influencing to be consider for
better code design. So our Null hypothesis (H 0) European software engineering conference and
proved true that if there are inter-related bad the ACM SIGSOFT symposium on The
smells in code, applying in different orders, foundations of software
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