Monitor-Based Instant
Software Refactoring
Hui Liu, Xue Guo, and Weizhong Shao
Presented By: Nitish R Sakhawalkar
Introduction
Software Refactoring is an effective method for improvement
of Software Quality while external behavior of Software
remains unchanged.
Maintainability, Extensibility and Reusability
Easy to add features and fix bugs with clean code.
Tool support in most IDEs.
What is a Code Smell ?
A Code Smell is a surface indication that usually corresponds
to a deeper problem in the system.
Example: Very long methods
They do not always indicate problems.
Detection of code smells and elimination leads to better
quality.
Better smell detection -> Better Programming
Need of Monitor-Based
Refactoring Tools
Existing tools are passive and human driven.
Developers
May not know how to invoke them
May forget to invoke them
Numerous critical refactoring opportunities may go unnoticed.
Increased smell life span due to delayed refactoring.
Related Work
Refactoring Tools
Refactoring Browser,
JRefactory, IntelliJ IDEA, Eclipse
and Visual Studio.
Existing tools are human
driven.
Time and frequency of
refactoring depend on software
developers.
Related Work
Smell Detection
Tools for Automatic and Semi-Automatic Detection of Smells.
Tourwe and Mens used Logic Rules.
Moha et al. used a Domain Specific Language (DSL) to specify
bad smells.
Munro and Van Rompaey et al. proposed a metric based
approach.
Tsantalis et al. proposed algorithms for specific smells. (ex:
Code Clones)
Integrated Code Smell Detection like Checkstyle, PMD and
FindBugs.
Related Work
Metric and Code Inspection Tools
IDEs show metrics in warning
colours, prompting the devs to
make changes.
Code Inspection tools for
Software Quality. They focus on
error fixing rather than
Software Refactoring.
Framework
Monitor
Analyses changes instantly and
decides the detection tools to
be invoked.
To minimize performance
impact, monitor minimizes the
frequency of invocation of
tools.
Accumulate changes
Minimization of search scope
Time consuming smell
detection runs in background
Framework
Smell Detectors and Refactoring
Tools
Existing Refactoring Tools.
Different detection algorithms
Minimize search scope.
Adapt algorithms to take full
advantage of minimized search
scope.
Ex: Incremental detection
Framework
Feedback Controller
Code smells are subjective;
detection algorithms leave
initialization of thresholds to user.
Proposed framework optimizes
thresholds automatically.
Precision is calculated.
Low Precision -> Increase
Threshold
High Precision -> Decrease
Threshold
Framework
Feedback Controller
Feedback Control Algorithm for Long
Parameter List is
;
Framework
Smell View
Detected Code Smells are presented to developers in a
friendly manner.
The view eye catching, but low key.
The presence or update of these views, does not block editors.
Evaluation
Research Questions
RQ1: Does instant refactoring make IDEs unresponsive?
RQ2: Does instant refactoring result in larger number of resolved
smells? If so, by how much?
RQ3: Does instant refactoring shorten the life span of code
smells? If so, by how much?
RQ4: Does the effect of instant refactoring vary with the type of
code smells? If so, which kind of code smells would benefit most?
Evaluation
Prototype Implementation
Implemented as an Eclipse plugin called InsRefactor.
Detection Algorithms for Data Class, Large Class, Long
Method, Switch Statements, Public Field, Common Method in
Sibling Classes, Duplicate Code, and Long Parameter List.
Smell types, explanations are provided in order, in Smell View.
Smell detection is run in a separate parallel thread.
Prototype
InsRefactor Plug-in Running
Prototype
InsRefactor Plug-in Running
Evaluation
Setup: Participant, Subject &
Tools
Graduate CS Majors divided into 2 groups. EG and CG.
Each group was of 10 students with knowledge of Eclipse.
Software to be Developed: UML Modeling tool.
EG used InsRefactor, while CG used InsRefactor’.
InsRefactor’ – Does not present code smells to devs.
InsRefactor and InsRefactor’ implement the same smell detection
algorithms.
Evaluation
Setup: Process
The evaluation process was as follows:
Engineers were given requirements together.
EG was provided with Eclipse + InsRefactor, CG was provided with
Eclipse + InsRefactor’.
Deadline of 10 days. Participants were told that their submission
would be evaluated according to both functionality and quality.
Experiments were conducted with standard hardware
environment.
Evaluation
Setup: Measurement
For RQ1, IDE unresponsiveness, subjective feedback was
collected.
For RQ2, was calculated.
For RQ3, was calculated. Non-refactored smells were ignored.
For RQ4, Increase in Smell Probability of being resolved (ISP),
Reduction In Lifespan of resolved smells (RIL) and Reduction in
Number of Introduced smells (RINI) was calculated for each smell.
Results and Analysis
No serious effect on IDE
Feedback from the developers suggests that there was no
serious effect on IDE performance.
Engineers were asked, “Is the IDE responsive?” with options,
“yes, seriously”, “yes, a bit”, “no, not at all”.
All the involved engineers selected, “no, not at all”.
Results and Analysis
Higher Software Quality
Teacher graded the assignments, providing a subjective
evaluation of the functionality and the quality.
EG achieved higher
grades.
Results and Analysis
Larger number of resolved
smells
Results and Analysis
Larger number of resolved
smells
Results and Analysis
Larger number of resolved
smells
Results and Analysis
Shorter Lifespan of Resolved
Smells
Results and Analysis
Effects on Different Types of
Smells
Threats to Validity
Difference in participants and their refactoring method.
Final comparison is based on groups, which will reduce the impact.
Participants are graduate students.
This is because it is not possible to have 20 experienced software engineers for experiment for 10 days.
Experiment is conducted on a single application.
Further evaluation on more applications is required.
Only 8 types of code smells have been monitored.
These are the most popular types of Code Smells, and are easier to detect than others.
Developers were given plenty of time.
Instant refactoring is better because the time spent is compensated by reduced efforts in maintenance.
Working time is not distinguished with non-working time.
Difficult, as developers maybe thinking even if not coding.
Counting resolved smells based on their disappearance maybe inaccurate.
Can be removed by directly counting applied refactoring.
Conclusions
Target users
Inexperienced developers need reminders because they lack consciousness of the urgency of
resolution. The Instant Refactoring helps train them.
Also helpful for experienced engineers. Time interval between successive invocation of smell
resolution can also be increased.
Extensibility
Can be easily extended to other smell detection algorithms.
Refactoring earlier vs later
In some cases refactoring earlier may lead to unnecessary refactorings.
Warning vs Training
An alternative approach is to train users using this tool, to improve software quality.
Static vs Dynamic Thresholds
Static thresholds can be set according to needs of organization.
Detection of Bad Names
Determining whether the name conveys the intent of the source code is difficult.
Conclusion and Future Work
Monitor based instant refactoring framework has been
presented, and evaluated.
Results show that it could drive inexperienced users to resolve
more code smells.
Future work is needed to extend framework to deal with more
code smells.
Resource consuming smell detection component should be
restructured for higher performance.
Future work with regards to evaluation is also necessary.
Strengths and Weaknesses
Strengths
Very effective framework, and works as described.
Most of the possible weaknesses have been considered and explained.
Weaknesses
Efficiency may reduce after adding other types of code smells.
Not practical in modern Agile Development Methodology.
Author do not compare with other automatic smell detection
techniques.
Ex: Paper from 2012
Should be tested in practical industry settings.
Questions?
