1. Do Metrics Help to Identify Refactoring? Jean-Guy Schneider (jschneider@swin.edu.au)jschneider@swin.edu.au Rajesh Vasa (rvasa@swin.edu.au)rvasa@swin.edu.au Leonhard Hoon (lhoon@swin.edu.au)lhoon@swin.edu.au

2. A Personal Note

3. Overview Background, Motivation What is Refactoring?  Detecting Refactoring Change Patterns Our Approach Pilot Study Summary, Concluding Remarks

4. Cost of Change Development Stage AnalysisDesign Coding “traditional” agile Source: Steve Hayes (Personal Communication)

5. Cost of Change (cont.) 5 The flat cost curve of agile development methodologies can only be achieved by introducing appropriate engineering techniques.  Refactoring is the most prominent of these technique.  Hypothesis: refactoring is applied frequently in projects with an iterative development process.

6. What is Refactoring? 6 “Refactoring is the the redistribution and/or rearrangement of methods, variables and classes across an object-oriented application without changing its observable semantics.”  Definition of catalogues of knows refactorings (cf., for example, catalogue by Martin Fowler http://refactoring.com/catalog/index.html) http://refactoring.com/catalog/index.html

7. But what about…? 7 Class ValidatorPlugIn (Struts 1.2.1): new Boolean (this.stopOnFirstError) Class ValidatorPlugIn (Struts 1.2.4): this.stopOnFirstError ? Boolean.True : Boolean.False

8. Detecting Refactorings 8 1. Manual code inspection (possibly in combination with “diff” tools) 2. Change detection using abstract system models (e.g., abstract syntax trees) 3. Mining source code control logs/release notes 4. Metrics extraction combined with heuristics 5. Usage logs of IDEs with built-in refactoring support (e.g., Eclipse)

9. Challenges and Limitations Comprehensive analysis often hindered by  system size(s),  considerable time difference between releases. Existing approaches focus on detecting (a few) selected known refactorings.  Catalogue of Martin Fowler contains 93 refactorings Combinations of refactoring and functional change cannot always be adequately identified. Not always possible to (semi-automatically) decide whether changes preserve observable semantics. 9

10. Code resists change (Vasa Ph.D.) A longitudinal study comprising 50 systems (over 1000 distinct releases):  70% of classes do not change between consecutive releases.  Only a small proportion of classes change multiple times over the entire lifetime (< 10%)  Magnitude of change is small (few lines of code)  The popularity of a class is the best determinant of change (rather than complexity or size)  Lehman’s laws are at work at the micro level too 10

11. Example: Struts 11

12. Our Approach Instead of attempting to explicitly detect known refactorings, use change metrics to identifty non-refactorings. Idea: use targetted refactoring detection for changes that are not identified as non-refactorings. Change detection per class using:  fully-qualified class name (incl. visibility, package)  set of 54 different metrics covering size, complexity and dependencies. Changes classified as (non-)refactoring manually in pilot study. 12

13. Pilot Study: Struts 13

14. Distribution Scatter (1.1 vs. 1.2.1) 14

15. Distribution Scatter (1.1 vs. 1.2.1) 15

16. Findings 16 Small changes (wrt both measures) are more likely to be refactorings Large changes are most likely not pure refactorings  But what is “small” and what is “large”?  No conclusive picture can be drawn

17. Conclusions and Future Work Change metrics alone not enough to reliably detect type of change  Small changes are more likely refactoring  Big changes are most likely not pure refactorings  Extend pilot study to get a clearer picture Better support needed to determine semantic preserving changes Definition of refactoring too broad  Many identified refactorings not part of a catalogue  Refactoring vs. Restructuring 17

18. Thank you for your attention… 18 Questions?