The lifecycle of code smells and transformations that introduced them - BETCON 2018

In software development, change is the only constant, and most of the effort during a software system life cycle is spent to support its evolution. However, software evolution is mostly driven by perfective and corrective maintenance, while preventive maintenance, e.g., improving code quality or the system’s organization, is rather insufficient of left for later by developers. Consequently, developers may introduce design violations, code smells, or bugs, that will persist in the system. In this presentation, we will: (i) visit related work on the importance of checking and removing code smells early in the software lifecycle; and we will (ii) show recent work on recommending code transformations for developers to automatically correct code smells and lead the software system to a more desirable state.

Transcript

1. The lifecycle of code smells and transformations that introduced them Gustavo Santos
2. Main Goal ‒ Importance of identifying and correcting symptoms of poor design early ‒ Recent work on automatically proposing correction for developers
3. Software Evolution ‒ Change is the only constant ‒ Code transformations on a daily basis ‒ Manual code edition, or ‒ Eventual automated support (refactoring tools)
4. Problem ‒ Motivated by perfective and corrective maintenance ‒ Preventive activities are done inefficiently or left for later [1] ‒ System might undergo an undesirable state [1] Javier Perez. Refactoring Planning for Design Smell Correction. ICSM 2013
5. Code Smells ‒ Indication or symptom of poor design ‒ Impact concerning technical debt and
 decrease in maintainability ‒ Developers rarely use refactoring tools
 to remove smells [2] [2] Silva et al. Why we refactor? Confessions of GitHub contributors. FSE 2016
6. The longevity of code smells
7. Chatzigeorgiou and Manakos [3] ‒ Two systems: JFlex and JFreeChart ‒ Four smells: God Class, Feature Envy, Long Method and State Checking ‒ Categories of persistence [3] Investigating the evolution of code smells in object-oriented systems. Innovations in Systems and Software Engineering. 2014
8. Categories of Persistence Start of Analysis
9. Categories of Persistence Category A Start of Analysis
10. Categories of Persistence Category A Category B Start of Analysis
11. Categories of Persistence Category A Category B Start of Analysis Category C
12. Categories of Persistence Category A Category B Start of Analysis Category C Category D
13. Chatzigeorgiou and Manakos [3] ‒ 57% smells appeared in all versions (A) ‒ 90% of smells, when appeared, persisted in all versions (A + B) ‒ No preventive maintenance was realized ‒ Eventual decrease of smells via removing the functionality altogether
14. Tufano et al. [4] ‒ Three ecosystems: Android, Apache, and Eclipse ‒ Five smells: Blob Class, Complex Class, Functional Decomposition, Spaghetti Code, Class Data should be private ‒ 579k commits [4] When and why your code starts to smell bad. ICSE 2015
15. Tufano et al. [4] ‒ At least half of smells are introduced when a code entity is added to the code base ‒ Code smell appear fast and not gradually ‒ Mainly introduced during an enhancement, mostly at the last month before a new release
16. The Pharo case
17. pharo.org ‒ Programming language and environment ‒ Open-source ‒ Applied in industrial and research projects ‒ Two years of analysis ‒ ~6k commits
18. Evolution of code smells A B C D ‒ 3855 (82%) ‒ 482 (10%) ‒ 317 (7%) ‒ 43 (~1%)
19. Transformations introducing smells ‒ Categories B and D ‒ Apriori algorithm ‒ Most frequent associations include:
 Add Method
 Add Method Invocation
 Remove Method Invocation
 Remove Method
20. Transformations introducing smells
21. Time to fix ‒ Categories C and D ‒ Did developers effectively removed the smells?
22. Automated support for developers
24. Recorder e.g., Epicea, Mylyn event: ClassWasMoved ——————————-———— + class: WindowAnnouncement + srcPackage: “Morphic-Base” + tgtPackage: “Morphic-Window”
25. Recorder Quality Rule: “a subclass must be in the same package as its superclass” e.g., Epicea, Mylyn event: ClassWasMoved ——————————-———— + class: WindowAnnouncement + srcPackage: “Morphic-Base” + tgtPackage: “Morphic-Window”
26. Recorder Transformation Tool Quality Rule: “a subclass must be in the same package as its superclass” e.g., Epicea, Mylyn e.g., Refactoring, Eclipse new MoveClass( WindowActivated, “Morphic-Windows”); event: ClassWasMoved ——————————-———— + class: WindowAnnouncement + srcPackage: “Morphic-Base” + tgtPackage: “Morphic-Window”
27. Transformation Opportunity I ‒ “Related classes should be in the same package” ‒ Scattered Functionality [Garcia et al., 2009]
 Broken Modularization [Suryanarayana et al., 2014]
 Misplaced Class [Fowler et al., 1999] ‒ Scenario for Move Class: “If subclasses of a moved class are in the former package, recommend to move them as well”
28. Preliminary Results — Move Class ‒ Project PolyMorph
 132 Move Class transformations ‒ 79 recommendations
 62 correct recommendations 78% precision
 32% recall
29. Transformation Opportunity II ‒ “Hierarchy must separate common behavior” ‒ Code clone [Fowler et al., 1999]
 Unfactored Hierarchy [Suryanarayana et al., 2014]
 Sibling Duplication [InFusion, 2016]
 Repeated Functionality [Arévalo, 2005] ‒ Scenario for Extract Method: “If the extracted method’s code is repeated along the subclasses, mark them invoke the method instead.”
30. Preliminary Results — Extract Method ‒ Pharo’s Icon Management
 19 Extract Method + 389 Code Replacement ‒ 352 recommendations
 336 correct recommendations 95% precision
 71% recall
31. Current Work ‒ Integrate solution in Pharo ‒ New transformation opportunities
 suggested by core developers ‒ Improve current refactoring and user experience
32. Thank you http://gustavojss.github.io/