Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Code Smell Research: History and Future Directions Second PLOW Installment - March 5, 20141 Nikolaos Tsantalis Computer Science & Software Engineering."— Presentation transcript:

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

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

3 3

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

5 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, 20146

7 7

8 8

9 9

10 10

11 Second PLOW Installment - March 5, 201411

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

13 Second PLOW Installment - March 5, 201413

14 Second PLOW Installment - March 5, 201414

15 Second PLOW Installment - March 5, 201415

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, 201416

17 Second PLOW Installment - March 5, 201417

18 Second PLOW Installment - March 5, 201418

19 Second PLOW Installment - March 5, 201419

20 Second PLOW Installment - March 5, 201420

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, 201421

22 Second PLOW Installment - March 5, 201422

23 Second PLOW Installment - March 5, 201423

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, 201424

25 Second PLOW Installment - March 5, 201425

26 Second PLOW Installment - March 5, 201426 LIMITATION

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, 201427

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, 201428

29 Second PLOW Installment - March 5, 201429

30 Second PLOW Installment - March 5, 201430

31 Second PLOW Installment - March 5, 201431

32 Second PLOW Installment - March 5, 201432 doStateA(); if state == STATE_A else if state == STATE_B doStateB();

33 Second PLOW Installment - March 5, 201433

34 Second PLOW Installment - March 5, 201434

35 Second PLOW Installment - March 5, 201435

36 Second PLOW Installment - March 5, 201436

37 Second PLOW Installment - March 5, 201437

38 Second PLOW Installment - March 5, 201438

39 Second PLOW Installment - March 5, 201439

40 Second PLOW Installment - March 5, 201440

41 Second PLOW Installment - March 5, 201441

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

43 Second PLOW Installment - March 5, 201443

44 Second PLOW Installment - March 5, 201444

45 Second PLOW Installment - March 5, 201445

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, 201446

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, 201447

48 Second PLOW Installment - March 5, 201448

49 Second PLOW Installment - March 5, 201449

50 Second PLOW Installment - March 5, 201450

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

52 Second PLOW Installment - March 5, 201452

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

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

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, 201455

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, 201456

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, 201457

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

59 Second PLOW Installment - March 5, 201459


Download ppt "Code Smell Research: History and Future Directions Second PLOW Installment - March 5, 20141 Nikolaos Tsantalis Computer Science & Software Engineering."

Similar presentations


Ads by Google