Code Smell Research: History and Future Directions Second PLOW Installment - March 5, 20141 Nikolaos...
-
Upload
oswald-berry -
Category
Documents
-
view
221 -
download
0
Transcript of Code Smell Research: History and Future Directions Second PLOW Installment - March 5, 20141 Nikolaos...
Second PLOW Installment - March 5, 2014 1
Code Smell Research:History and Future Directions
Nikolaos TsantalisComputer Science & Software Engineering
Second PLOW Installment - March 5, 2014 2
Preventive Software Maintenance
Changes aiming to improve the future maintainability and reliability of the software system.
Why is it so necessary?
3
Software aging
Refactoring
Second PLOW Installment - March 5, 2014 4
• Refactoring Object-oriented Frameworks, University of Illinois at Urbana-Champaign– Introduced the concept of refactorings as behavior-
preserving program restructuring operations.– Introduced the concept of preconditions as
conditions that should be examined to determine whether a refactoring can be applied safely.
1992The Genesis
Second PLOW Installment - March 5, 2014 5
1999
The Past
Second PLOW Installment - March 5, 2014 6
Martin FowlerRefactoring
Duplicated Code:“If you see the same code structure in more than one place, … find a way to unify them.”
Second PLOW Installment - March 5, 2014 7
1999
The Past
2001
Second PLOW Installment - March 5, 2014 8
Frank Simon, Claus LewerentzMetrics Based Refactoring
CSMR MostInfluential
Paper Award
Second PLOW Installment - March 5, 2014 9
1999
The Past
20012002
Second PLOW Installment - March 5, 2014 10
Eva van Emden, Leon MoonenAssuring Software Quality by Code Smell Detection
WCRE MostInfluential
Paper Award jCosmo
Second PLOW Installment - March 5, 2014 11
1999
The Past
20012003
2002
Second PLOW Installment - March 5, 2014 12
Tom Tourwé, Tom MensLogic Meta Programming
Code smell definition for Inappropriate InterfaceinappropriateInterface(?class,?interface,?subclasses) :- findall(<?itf,?scs>, commonSubclassInterface(?class,?itf,?scs), ?result), removeDuplicates(?result,?nodups), member(<?interface,?subclasses>,?nodups)
Second PLOW Installment - March 5, 2014 13
1999
The Past
20012003
20022005
Second PLOW Installment - March 5, 2014 14
Radu MarinescuDetection Strategies
Second PLOW Installment - March 5, 2014 15
1999
The Past
20012003
20022005
2008
Second PLOW Installment - March 5, 2014 16
Mel O’Keeffe, Mel Ó CinnéideSearch-based Refactoring
• Treat the improvement of object-oriented design as a search problem in the space of alternative designs
• The move in the search space is achieved by modeling refactorings (inheritance-related)
• Apply search algorithms using QMOOD as the fitness function (rank alternative designs)
• The outcome is a sequence of refactorings leading to the optimal design
Second PLOW Installment - March 5, 2014 17
1999
The Past
20012003
20022005
20082009
Second PLOW Installment - March 5, 2014 18
Naouel Moha, Yann-Gaël GuéhéneucDECOR
Second PLOW Installment - March 5, 2014 19
Second PLOW Installment - March 5, 2014 20
Why don’t we use historical informationto find code smells?
ACM DistinguishedPaper Award
ASE 2013
F. Palomba , G. Bavota, M. Di PentaHIST
Second PLOW Installment - March 5, 2014 21
Many code smell definitions are based on historical change information– Shotgun Surgery: When every time you make a
kind of change, you have to make a lot of little changes to a lot of different classes.
– Parallel Inheritance Hierarchies: When every time you make a subclass of one class, you also have to make a subclass of another.
Code smells + Change history
Patterns of changes repeated over time
Second PLOW Installment - March 5, 2014 22
Association Rule Discoveryin the Change History
Second PLOW Installment - March 5, 2014 23
ICSE 2013
What are the interactions among code smellsand how they affect maintenance?
Aiko Yamashita, Leon MoonenInter-smell Relations
Second PLOW Installment - March 5, 2014 24
• 12 code smells• 6 Professional developers were hired to
implement change requests• 4 medium-sized Java systems with known
code smells• 4 weeks of development• Daily interviews and think-aloud sessions
Empirical Study design
Second PLOW Installment - March 5, 2014 25
Code Smell Relationships
Second PLOW Installment - March 5, 2014 26
The Other Side of the Coin
Code Smells RefactoringOpportunities
LIMITATION
Second PLOW Installment - March 5, 2014 27
Refactoring Opportunities
Advantages:Feasible and behavior preserving solutions
to design problemsRanking and prioritizing solutions based on
their expected effect on design qualityA holistic approach for preventive
maintenance
Second PLOW Installment - March 5, 2014 28
1. Identify places where software should be refactored (known as bad smells).
2. Determine which refactoring(s) should be applied to the identified places.
3. Guarantee that the applied refactoring preserves behavior.4. Apply the refactoring.5. Assess the effect of the refactoring on quality
characteristics of the software.6. Maintain the consistency between the refactored code
and other software artifacts.
Holistic solutionTSE 2004
Second PLOW Installment - March 5, 2014 29
2009
The history of refactoring opportunities
Second PLOW Installment - March 5, 2014 30
#1 Misallocatedbehavior in classes
Tsantalis & ChatzigeorgiouIEEE TSE, 2009
Second PLOW Installment - March 5, 2014 31
2009
The history of refactoring opportunities
2010
Second PLOW Installment - March 5, 2014 32
Context
+ method() {state.method();
}
- type : int- STATE_A : int = 1 - STATE_B : int = 2
#2 Conditional logicvs. Polymorphism
State
+method()
StateB
+method() {
}
StateA
+method() {
}
Context
+ method() {
}
- state : int- STATE_A : int = 1 - STATE_B : int = 2
doStateA();if state == STATE_A
elseif state == STATE_B doStateB();
state
Tsantalis & ChatzigeorgiouJSS, 2010
Second PLOW Installment - March 5, 2014 33
2009
The history of refactoring opportunities
2010 2011
Second PLOW Installment - March 5, 2014 34
#3 Long & Complex methods
Tsantalis & ChatzigeorgiouJSS, 2011
Second PLOW Installment - March 5, 2014 35
2009
The history of refactoring opportunities
2010 2011 2012
Second PLOW Installment - March 5, 2014 36
#4 Large & Complex classes
70 methods15 fields900 LOC
19 methods11 fields
Fokaefs et al. JSS, 2012
Bavota et al. JSS, 2011
Second PLOW Installment - March 5, 2014 37
2009
The history of refactoring opportunities
2010 2011 2012 2013
Second PLOW Installment - March 5, 2014 38
#5 Generalization of common interfaces or functionalities
Liu et al. Autom Softw Eng, 2013
Second PLOW Installment - March 5, 2014 39
2009
The history of refactoring opportunities
2010 2011 2012 2013 2014
Second PLOW Installment - March 5, 2014 40
#6 Software Clones
Krishnan & TsantalisCSMR-WCRE, 2014
Second PLOW Installment - March 5, 2014 41
TOOLS
Second PLOW Installment - March 5, 2014 42
20+ academic licensesSince the beginning of 2011 …
8,000 applied refactorings5,000 marketplace installations
Second PLOW Installment - March 5, 2014 43
State-of-the-art commercial tools
Technical debt assessmentComputer-aided refactoring
Live code smell detectionSmart visualizations
Second PLOW Installment - March 5, 2014 44
So, tools are adopted
What’s next?
Management ofCode Smells
Second PLOW Installment - March 5, 2014 45
Motivation
Not all code smells are equally important
Why should we refactora piece of code that never changes?
a piece of code that is not used?
a piece of code that is not involved in bugs?
Second PLOW Installment - March 5, 2014 46
Technical debtmanagement
• “Debt” is the effect of incomplete, immature, or inadequate maintenance activities
• Delayed tasks may bring a short-term benefit (higher productivity, shorter release time)
• Might have to be paid back in the future with “Interest” (increased effort)
• “Principal” is the effort to pay off the debt
Second PLOW Installment - March 5, 2014 47
Clone management
• Tracking clones as project evolves• Verifying the consistent modification of clones• Updating clones and groups as project evolves• Assessing the harmfulness of clones
Second PLOW Installment - March 5, 2014 48
M. Mondal, C. Roy
CSMR-WCRE 2014
Why don’t we use historical informationto rank clones for refactoring?
Second PLOW Installment - March 5, 2014 49
Similarity Preserving Change Pattern
If the clones co-change by preserving their similarity,they should have higher priority for refactoring
Second PLOW Installment - March 5, 2014 50
Second PLOW Installment - March 5, 2014 51
• So far, we used– Static source code analysis– Semantic analysis– Change history analysis
Research direction #1Alternative code smell detection
What aboutdeveloper collaboration patterns
the history of bug resolutions
Second PLOW Installment - March 5, 2014 52
In other words...
MSR for detecting code smellsand refactoring opportunities
Second PLOW Installment - March 5, 2014 53
Research direction #2Risk Management
Every code smell involves a certain risk
for future maintainability
What is the risk of leavinga code smell in the system?
Second PLOW Installment - March 5, 2014 54
Risk Assessment
• Likelihood of occurrence of the risky event• Exposure of the system to the event• Consequence of the event
Risk = Likelihood × Exposure × Consequence
Second PLOW Installment - March 5, 2014 55
Likelihood estimation
• Risky events changes driven by code smells– Ex. 1: Fixing the same bug in a clone group– Ex. 2: Making a method more “envy” to another class
• Intuition: code that changes frequently due to a design flaw imposes a high risk to the maintainability of a system
• Likelihood proneness to code smell driven changes (estimated from the history of changes)
Second PLOW Installment - March 5, 2014 56
Exposure estimation
• Intuition: the more extensively a module is used, the more extensive the propagation of code smell driven changes to dependent modules
• Exposure the number and strength of incoming dependencies (estimated from static and dynamic analysis)
Second PLOW Installment - March 5, 2014 57
Consequence estimation
• Consequence cost of code smell driven changes (effort, time, money).
From the opposite perspective:• Consequence effect of removing the code
smell.• Estimated by computing the impact of the
corresponding refactoring on metrics.
Second PLOW Installment - March 5, 2014 58
Given a set of different types of refactoring opportunities in a software system
• Conflicts• Dependencies
Research direction #3Refactoring Scheduling
How can we find an order that maximizesthe number of applied refactorings?
Second PLOW Installment - March 5, 2014 59
Visit our project athttp://jdeodorant.com