Why Refactor ?

1. WhyRefactor? • Imagine you’ve written a piece of code but then accidentally deleted and lost it. • Questions: • How much time would it take you to reconstruct from scratch what you had – the same amount, or more, or less? • Would the code have a better design the second time youwriteit? • Imagine you are doing software maintenance. • Observations: • It’s harder to maintain (someone else’s) code than it is to write new code. • Most developers hope that they won’t have to deal with code maintenance. • Evolving/maintaining code is what most developers do most of the time. • Good engineering: keep code simple and easy to understand. • Problem: code is hard to evolve and maintain • Solution: refactor to keepit simple “Any fool can write code that a computer can understand. Good programmers write code that humanscanunderstand." MartnFowler CSC7302: Testing & Metrics

2. WhatisRefactoring? • “[Refactoring is] the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” – Martin Fowler • Changes made to a system that: • Do not change observable behavior • Remove duplication or needless complexity • Enhance software quality • Make the code easier and simpler to understand • Make the code more flexible • Make the code easier to change, etc… • NOTE: the importance of – • Tests • Metrics CSC7302: Testing & Metrics

3. WhyRefactor? …. Revisited • Long-term investment in the quality of the code and its structure • No refactoring may save costs / time in the short term but incurs a huge penalty in the long run • Why fix if it ain’t broken? • Every module has three functions: • To execute according to its purpose • To afford change • To communicate to its readers • If it does not do one or more of these, it is broken. CSC7302: Testing & Metrics

4. When to Refactor? • NOT: 2 weeks every 6 months • Do it as you develop - Opportunistic Refactoring • Boy Scout principle: leave it better than you foundit. • If you recognize a warning sign (a bad smell) • When you add a function • Before, to start clean and/or • After, to clean-up • When you fix a bug • Whenyou code review • You can use The Rule of Three (Fowler – XP) • The first time, just do it! • ! Need it somewhere else? Cut and paste it! • ! The third time, refactor! CSC7302: Testing & Metrics

5. WhenNot to Refactor? When the tests are failing When you should just rewrite the code When you have impending deadlines How to Refactor? CSC7302: Testing & Metrics

6. Bad Smells in Code: (Refactoring, chp3, Martin Fowler) CSC7302: Testing & Metrics

7. Bad Smells in Code: (Refactoring, chp3, Martin Fowler) CSC7302: Testing & Metrics

8. Refactoring Drawbacks • Whentakentoo far • Incessant tinkeringwith code • Trying to make it perfect • Attempting refactoring when the tests don’t work – or without tests – can lead to dangerous situations! • Refactoring published interfaces propagates to external users relying on these interfaces CSC7302: Testing & Metrics

9. WhyDevelopersFearRefactoring? • 1. “I don’t understand the code enough to do it” • 2. Short-term focus (Adding a new working feature is cooler!) • 3. Not paid for overhead tasks such as refactoring? • Solutions: • 1. Test, test and test again, with good test code. • 2. Learn to appreciate elegant code (and find good metrics) • 3. Teach the benefits of better code (to your colleagues) CSC7302: Testing & Metrics

10. Recommended Reading Susan L. Gerhart. 1975. Correctness-preserving program transformations. In Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '75). ACM, New York, NY, USA, 54-66. DOI=10.1145/512976.512983 David B. Loveman. 1977. Program Improvement by Source-to-Source Transformation. J. ACM 24, 1 (January 1977), 121-145. DOI=10.1145/321992.322000 R.J.R. Back, On correct refinement of programs, Journal of Computer and System Sciences, Volume 23, Issue 1, August 1981, Pages 49-68, ISSN 0022-0000, 10.1016/0022-0000(81)90005-2. William F. Opdyke. 1992. Refactoring Object-OrientedFrameworks. Ph.D. Dissertation. University of Illinois at Urbana-Champaign, Champaign, IL, USA. UMI Order No. GAX93-05645. Fowler, Beck, Bravnt, Opdyke, Roberts, Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA., 1999, ISBN: 978-0201485677 . (Chapter3: Bad Smells In Code, p75-87, Fowler, Beck) Lance Tokuda and Don Batory. 1999. Evolving Object-Oriented Designs with Refactorings. In Proceedings of the 14th IEEE international conference on Automated software engineering (ASE '99). IEEE Computer Society, Washington, DC, USA. (From PhD Thesis, Tokuda: University of Texas at Austin) CSC7302: Testing & Metrics

11. Recommended Reading Frank Simon, Frank Steinbruckner, and Claus Lewerentz. 2001. MetricsBasedRefactoring. In Proceedings of the FifthEuropeanConference on Software Maintenance and Reengineering (CSMR '01). IEEE Computer Society, Washington, DC, USA. Arie van DeursenLeonMoonen Alex van den Bergh Gerard Kok, Refactoring Test Code, Technical Report, Software Improvement Group, The Netherlands, 2001 E. Van Emden and L. Moonen. 2002. Java Quality Assurance by Detecting Code Smells. In Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE'02) (WCRE '02). IEEE Computer Society, Washington, DC, USA Tom Mens and Tom Tourwé; 2004. A Survey of Software Refactoring. IEEE Trans. Softw. Eng. 30, 2 (February 2004), 126-139. DOI=10.1109/TSE.2004.1265817 Konstantinos Stroggylos and DiomidisSpinellis. 2007. Refactoring--Does It Improve Software Quality?. In Proceedings of the 5th International Workshop on Software Quality (WoSQ '07). IEEE Computer Society, Washington, DC, USA, 10-. DOI=10.1109/WOSQ.2007.11 Robert M. Fuhrer, Markus Keller, Adam Kiezun: Advanced Refactoring in the Eclipse JDT: Past, Present, and Future. WRT 2007: 30-31 Emerson Murphy-Hill, Chris Parnin, and Andrew P. Black. 2009. How we refactor, and how we know it. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 287-297. DOI=10.1109/ICSE.2009.5070529 CSC7302: Testing & Metrics

12. Java Refactoring – Built-in to Eclipse Source - Leif Frenzel: The Language Toolkit: An API for Automated Refactorings in EclipsebasedIDEs, http://www.eclipse.org/articles/Article-LTK/ltk.html Eclipse provides a general-purpose API for implementing refactorings that can be applied to any Eclipse workspace elements, from text resources to whole projects. Several plugins for Eclipse draw upon the API to implement refactorings for specific languages; here we will focus on refactorings implemented for Java. The Eclipse refactoring API, part of the Language Toolkit (LTK), is implemented within the org.eclipse.ltk.core.refactoring and org.eclipse.ltk.ui.refactoring plug-ins since R3.0 The API for refactoring provides a process-level abstraction upon which specific refactoringsmaybebuilt CSC7302: Testing & Metrics

13. Java Refactoring – Built-in to Eclipse Dependenciesbetweenrefactoring API elements CSC7302: Testing & Metrics

14. Java Refactoring – Built-in to Eclipse A refactorimplenter must extend the abstract class org.eclipse.ltk.core.refactoring.Refactoring There is a life cycle associated to suchrefactorings: A refactoring ultimately produces a single implementation of the abstract class Change that describes the workspace changes necessary to accomplish the refactoring. Implementers of refactorings must re-use or implement their own classes derived from Change to specify the behavior of a change. CSC7302: Testing & Metrics

15. Java Refactoring – Built-in to Eclipse • The Java part of Eclipse, JDT, is able to perform several types of automatic refactorings on Java projects, classes, and their members. There are several ways to quickly select a refactoring for an element in a Java project. • If you look in the Refactor dropdown menu in Eclipse, you will notice four sections: • The first section has Undo and Redo in it • The other three sections contain the three different types of refactorings available in Eclipse • contains refactorings that change the physical structure of the code and classes such as Rename and Move. • contains refactorings that change the code structure on a class level such as Pull Up and Push Down. • contains refactorings that change the code within a class such as Extract Method and Encapsulate Field CSC7302: Testing & Metrics

16. Java Refactoring – Built-in to Eclipse • Type 1 – Physical Structure • • Rename • • Move • • Change Method Signature • • Convert Anonymous Class to Nested • • Convert Nested Type to Top Level (Eclipse 2 only) • • Move Member Type to New File (Eclipse 3 only) • Type 2 – Class Level Structure • • Push Down • • Pull Up • • Extract Interface • • Generalize Type (Eclipse 3 only) • • User SupertypeWhere Possible • Type 3 – Structure inside a Class • • Inline • • ExtractMethod • • Extract Local Variable • • Extract Constant • • Introduce Parameter (Eclipse 3 only) • • Introduce Factory (Eclipse 3 only) • • Encapsulate Field TO DO: Experimentwith all the refactoringsthat are already in your version of Eclipse. You shouldbecomefamiliarwith all of them. CSC7302: Testing & Metrics

17. RefactoringCatalog (http://refactoring.com/catalog/index.html) CSC7302: Testing & Metrics