This document discusses the history and future directions of code smell research. It covers the origins of refactoring and code smells, definitions of various code smells, methods for identifying code smells, prioritizing refactoring opportunities based on risk analysis, and the need to consider refactoring dependencies and conflicts. The goal is to improve software maintainability and quality through addressing code smells.

1. Code Smell Research:
History and Future Directions
Nikolaos Tsantalis
Computer Science & Software Engineering
Second PLOW Installment - March 5, 2014
1

2. Changes aiming to improve the future
maintainability and reliability of the
software system.
Second PLOW Installment - March 5, 2014
2

3. 3

4. • Refactoring Object-oriented Frameworks,
University of Illinois at Urbana-Champaign
– Introduced the concept of refactorings as behaviorpreserving program restructuring operations.
– Introduced the concept of preconditions as
conditions that should be examined to determine
whether a refactoring can be applied safely.
Second PLOW Installment - March 5, 2014
4

5. Second PLOW Installment - March 5, 2014
5

6. 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
6

7. Second PLOW Installment - March 5, 2014
7

8. Second PLOW Installment - March 5, 2014
8

9. Second PLOW Installment - March 5, 2014
9

10. Second PLOW Installment - March 5, 2014
10

11. Second PLOW Installment - March 5, 2014
11

12. Code smell definition for Inappropriate Interface
inappropriateInterface(?class,?interface,?subclasses) :findall(<?itf,?scs>,
commonSubclassInterface(?class,?itf,?scs),
?result),
removeDuplicates(?result,?nodups),
member(<?interface,?subclasses>,?nodups)
Second PLOW Installment - March 5, 2014
12

13. Second PLOW Installment - March 5, 2014
13

14. Second PLOW Installment - March 5, 2014
14

15. Second PLOW Installment - March 5, 2014
15

16. • 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
16

17. Second PLOW Installment - March 5, 2014
17

18. Second PLOW Installment - March 5, 2014
18

19. Second PLOW Installment - March 5, 2014
19

20. Second PLOW Installment - March 5, 2014
20

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.
Second PLOW Installment - March 5, 2014
21

22. Second PLOW Installment - March 5, 2014
22

23. Second PLOW Installment - March 5, 2014
23

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
Second PLOW Installment - March 5, 2014
24

25. Second PLOW Installment - March 5, 2014
25

26. Second PLOW Installment - March 5, 2014
26

27. Advantages:
Feasible and behavior preserving solutions
to design problems
Ranking and prioritizing solutions based on
their expected effect on design quality
A holistic approach for preventive
maintenance
Second PLOW Installment - March 5, 2014
27

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.
Second PLOW Installment - March 5, 2014
28

29. Second PLOW Installment - March 5, 2014
29

30. Second PLOW Installment - March 5, 2014
30

31. Second PLOW Installment - March 5, 2014
31

32. Context
State
state
- state::int
type int
- STATE_A : int = 1
- STATE_B : int = 2
+ method() {
state.method();
if state == STATE_A
} doStateA();
else
if state == STATE_B
doStateB();
}
+method()
StateA
StateB
+method() {
+method() {
}
}
Second PLOW Installment - March 5, 2014
32

33. Second PLOW Installment - March 5, 2014
33

34. Second PLOW Installment - March 5, 2014
34

35. Second PLOW Installment - March 5, 2014
35

36. Second PLOW Installment - March 5, 2014
36

37. Second PLOW Installment - March 5, 2014
37

38. Second PLOW Installment - March 5, 2014
38

39. Second PLOW Installment - March 5, 2014
39

40. Second PLOW Installment - March 5, 2014
40

41. Second PLOW Installment - March 5, 2014
41

42. Since the beginning of 2011 …
Second PLOW Installment - March 5, 2014
42

43. Second PLOW Installment - March 5, 2014
43

44. Second PLOW Installment - March 5, 2014
44

45. Second PLOW Installment - March 5, 2014
45

46. • “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
46

47. •
•
•
•
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
47

48. Second PLOW Installment - March 5, 2014
48

49. Second PLOW Installment - March 5, 2014
49

50. Second PLOW Installment - March 5, 2014
50

51. • So far, we used
– Static source code analysis
– Semantic analysis
– Change history analysis
Second PLOW Installment - March 5, 2014
51

52. Second PLOW Installment - March 5, 2014
52

53. Every code smell involves a certain risk
for future maintainability
Second PLOW Installment - March 5, 2014
53

54. • Likelihood of occurrence of the risky event
• Exposure of the system to the event
• Consequence of the event
Second PLOW Installment - March 5, 2014
54

55. • 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
55

56. • 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
56

57. • 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
57

58. Given a set of different types of refactoring
opportunities in a software system
• Conflicts
• Dependencies
Second PLOW Installment - March 5, 2014
58

59. Visit our project at
Second PLOW Installment - March 5, 2014
59