code smell research: history and future directions

Second PLOW Installment - March 5, 2014 1

Code Smell Research:History and Future Directions

Nikolaos TsantalisComputer Science & Software Engineering


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


• 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


1999

The Past


Martin FowlerRefactoring

Duplicated Code:“If you see the same code structure in more than one place, … find a way to unify them.”


1999

The Past

2001


Frank Simon, Claus LewerentzMetrics Based Refactoring

CSMR MostInfluential

Paper Award


1999

The Past

20012002


Eva van Emden, Leon MoonenAssuring Software Quality by Code Smell Detection

WCRE MostInfluential

Paper Award jCosmo


1999

The Past

200120032002


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)


1999

The Past

200120032002

2005


Radu MarinescuDetection Strategies


1999

The Past

200120032002

20052008


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


1999

The Past

200120032002

20052008

2009


Naouel Moha, Yann-Gaël GuéhéneucDECOR


Why don’t we use historical informationto find code smells?

ACM DistinguishedPaper Award

ASE 2013

F. Palomba , G. Bavota, M. Di PentaHIST


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


Association Rule Discoveryin the Change History


ICSE 2013

What are the interactions among code smellsand how they affect maintenance?

Aiko Yamashita, Leon MoonenInter-smell Relations


• 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


Code Smell Relationships


The Other Side of the CoinCode Smells Refactoring

Opportunities

LIMITATION


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


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


2009

The history of refactoring opportunities


#1 Misallocatedbehavior in classes

Tsantalis & ChatzigeorgiouIEEE TSE, 2009


2009


2010


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


2009


2010 2011


#3 Long & Complex methods

Tsantalis & ChatzigeorgiouJSS, 2011


2009


2010 2011 2012


#4 Large & Complex classes

70 methods15 fields900 LOC

19 methods11 fields

Fokaefs et al. JSS, 2012

Bavota et al. JSS, 2011


2009


2010 2011 2012 2013


#5 Generalization of common interfaces or functionalities

Liu et al. Autom Softw Eng, 2013


2009


2010 2011 2012 2013 2014


#6 Software Clones

Krishnan & TsantalisCSMR-WCRE, 2014


TOOLS


20+ academic licensesSince the beginning of 2011 …

8,000 applied refactorings5,000 marketplace installations


State-of-the-art commercial tools

Technical debt assessmentComputer-aided refactoring

Live code smell detectionSmart visualizations


So, tools are adopted

What’s next?

Management ofCode Smells


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?


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


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


M. Mondal, C. Roy

CSMR-WCRE 2014

Why don’t we use historical informationto rank clones for refactoring?


Similarity Preserving Change Pattern

If the clones co-change by preserving their similarity,they should have higher priority for refactoring


• 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


In other words...

MSR for detecting code smellsand refactoring opportunities


Research direction #2Risk Management

Every code smell involves a certain riskfor future maintainability

What is the risk of leavinga code smell in the system?


Risk Assessment

• Likelihood of occurrence of the risky event• Exposure of the system to the event• Consequence of the event

Risk = Likelihood × Exposure × Consequence


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)


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)


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.


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?


Visit our project athttp://jdeodorant.com

code smell research: history and future directions

Documents

concept of code smells

software system

code structure

future code smell research

detection of code smells

management of code smells

code smell definitions

design quality