Do Metrics Help to Identify Refactoring? Jean-Guy Schneider Rajesh Vasa Leonhard Hoon

A Personal Note

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

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

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.

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

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

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)

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

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

Example: Struts 11

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

Pilot Study: Struts 13

Distribution Scatter (1.1 vs ) 14

Distribution Scatter (1.1 vs ) 15

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

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

Thank you for your attention… 18 Questions?