An Initial Study on Refactoring Tactics

Software refactoring might be done in two different tactics. The first one is XP-style small-step refactoring, also called floss refactoring. The other tactic, called root canal refactoring, is to set aside an extended period specially for refactoring. Floss refactoring, as one of the corner stones of XP, is well acknowledged. In contrast, root canal refactoring is doubted, especially by XP advocators. Despite the doubts, however, no large scale empirical study on refactoring tactics has been reported. In contrast to the doubts, cases of root canal refactoring have been reported from industry, e.g., Microsoft. Researchers from academe have also proposed various approaches to facilitating root canal refactoring. To this end, this paper would investigate the following questions. (1)How often are the two different tactics employed, respectively? (2) Is there any correlation between refactoring tactics and categories of refactorings? In other words, are some kinds of refactorings more likely than others to be done as floss refactorings or root canal refactorings? To answer these questions, we analyze refactoring histories collected by Eclipse Usage Data Collector (UDC). The data are collected from 753,367 engineers worldwide. Analysis results suggest that about 11.5 percent of refactorings collected by UDC are root canal refactorings, whereas others (88.5 percent) are floss refactorings. We also find that some kinds of refactorings, e.g., Introduce Parameter, are more likely than others to be performed as root canal refactorings.

[1]  Andrew P. Black,et al.  Gathering refactoring data: a comparison of four methods , 2008, WRT '08.

[2]  Frank Tip,et al.  Refactoring for generalization using type constraints , 2003, OOPSLA '03.

[3]  E. Murphy-Hill,et al.  Refactoring Tools: Fitness for Purpose , 2006, IEEE Software.

[4]  Mik Kersten,et al.  How are Java software developers using the Elipse IDE? , 2006, IEEE Software.

[5]  Zhendong Niu,et al.  Facilitating software refactoring with appropriate resolution order of bad smells , 2009, ESEC/FSE '09.

[6]  B. Van Rompaey,et al.  On The Detection of Test Smells: A Metrics-Based Approach for General Fixture and Eager Test , 2007, IEEE Transactions on Software Engineering.

[7]  Zhiyi Ma,et al.  Scheduling of conflicting refactorings to promote quality improvement , 2007, ASE '07.

[8]  Giuliano Antoniol,et al.  A novel approach to optimize clone refactoring activity , 2006, GECCO.

[9]  G. Li,et al.  Conflict-aware schedule of software refactorings , 2008, IET Softw..

[10]  Zhenchang Xing,et al.  Refactoring Practice: How it is and How it Should be Supported - An Eclipse Case Study , 2006, 2006 22nd IEEE International Conference on Software Maintenance.

[11]  Yann-Gaël Guéhéneuc,et al.  Automatic Generation of Detection Algorithms for Design Defects , 2006, 21st IEEE/ACM International Conference on Automated Software Engineering (ASE'06).

[12]  Andrew P. Black,et al.  How we refactor, and how we know it , 2009, 2009 IEEE 31st International Conference on Software Engineering.

[13]  Shinji Kusumoto,et al.  CCFinder: A Multilinguistic Token-Based Code Clone Detection System for Large Scale Source Code , 2002, IEEE Trans. Software Eng..

[14]  Eleni Stroulia,et al.  UMLDiff: an algorithm for object-oriented design differencing , 2005, ASE.

[15]  Serge Demeyer,et al.  On The Detection of Test Smells: A Metrics-Based Approach for General Fixture and Eager Test , 2007, IEEE Trans. Software Eng..

[16]  M.J. Munro,et al.  Product Metrics for Automatic Identification of "Bad Smell" Design Problems in Java Source-Code , 2005, 11th IEEE International Software Metrics Symposium (METRICS'05).

[17]  Zhendong Niu,et al.  Schedule of Bad Smell Detection and Resolution: A New Way to Save Effort , 2012, IEEE Transactions on Software Engineering.

[18]  C MurphyGail,et al.  How Are Java Software Developers Using the Eclipse IDE , 2006 .

[19]  Yann-Gaël Guéhéneuc,et al.  DECOR: A Method for the Specification and Detection of Code and Design Smells , 2010, IEEE Transactions on Software Engineering.

[20]  Kent L. Beck,et al.  Extreme programming explained - embrace change , 1990 .

[21]  Rudolf K. Keller,et al.  Fit for Change: Steps towards Effective Software Maintenance , 2005, ICSM.

[22]  Alexander Chatzigeorgiou,et al.  Identification of Move Method Refactoring Opportunities , 2009, IEEE Transactions on Software Engineering.

[23]  Tom Mens,et al.  A survey of software refactoring , 2004, IEEE Transactions on Software Engineering.

[24]  William G. Griswold,et al.  Automated support for program refactoring using invariants , 2001, Proceedings IEEE International Conference on Software Maintenance. ICSM 2001.

[25]  William F. Opdyke,et al.  Refactoring object-oriented frameworks , 1992 .

[26]  Eleni Stroulia,et al.  Metrics of Refactoring-based Development: An Experience Report , 2001, OOIS.

[27]  William C. Wake,et al.  Refactoring Workbook , 2003 .

[28]  Tom Mens,et al.  Identifying refactoring opportunities using logic meta programming , 2003, Seventh European Conference onSoftware Maintenance and Reengineering, 2003. Proceedings..