Transcript PPT
CS494: Intro. to Refactoring • Readings: – Refactoring for everyone: How and why to use Eclipse's automated refactoring features. By David Gallardo (http://www-106.ibm.com/developerworks/opensource/library/os-ecref/) – Handout from Fowler’s Refactoring book – Optional: Refactoring: Benefits and Disadvantages…”. Web article. Refactoring - 1 Overview • Refactoring: what and why – Reminders: TDD and Unit Testing • Tool support • (Later: lab exercise) Refactoring - 2 What Is Refactoring? • Definition: – The process of changing software in a way that the external behavior is not altered but the internal structure is improved. – Or, an instance of such a change. (E.g. “I carried out a refactoring….”) • Cleaning up code. Improving design. But after the code works. – Fights against software entropy Refactoring - 3 Why Refactor? • Continuous improvement of design – “Tidying up.” Avoids decay. – Needed if “make it work” is first priority – Best design choices may not evident at first • Makes software easier to understand – Refactoring done to clean up hacks – Done after reflection. – May be done to remove ambiguity, misleading code, a hack, etc. – If you can change it successfully, you understand it Refactoring - 4 Why Refactor? (2) • Helps you find bugs – A change to improve structure may reveal a flaw in old implementation • Helps you developing working code more quickly – Counter-intuitive! – Short cycles of add-functionality then improve-design. (Kent Beck’s “two hats” idea). Refactoring - 5 But Hold On… • Possible objections…. – Touching the design is asking for trouble! – Once it’s working, why bother? – After I think it’s working, don’t I have to reverify the design changes again? • What we need to make refactoring successful is – Unit tests Refactoring - 6 Reminder slides • Remember unit tests? TDD? Refactoring - 7 Unit Testing in TDD • Motto: “Clean code that works.” (Ron Jeffries) • Unit testing has “broader goals” that just insuring quality – Improve developers lives (coping, confidence) – Support design flexibility and change – Allow iterative development with working code early Refactoring - 8 Unit Testing Benefits • Developers can work in a predictable way of developing code • Programmers write their own unit tests • Get rapid response for testing small changes • Build many highly-cohesive looselycoupled modules to make unit testing easier Refactoring - 9 Red/Green/Refactor • The TDD mantra of how to code: – Red: write a little test that doesn’t work, perhaps even doesn’t compile – Green: Write code to make the test work quickly (perhaps not the best code) – Refactor: Eliminate duplication and other problems that you did to just make the test work Refactoring - 10 When Should Refactor? • Remember: afterwards! (After what?) • “The Rule of Three” – First, just do it. Second time, do it badly but tolerate it. Third time, do it well: refactor. • Some guidelines: – When you need to add a function. Existing design makes this hard. Improve it. – When you need to fix a bug. – As part of a code review. Refactoring - 11 Refactoring and Design Smells • Fowler, design smells, and catalog of refactorings – The book – http://www.refactoring.com/ – List of smells on the web: http://wiki.java.net/bin/view/People/SmellsTo Refactorings Refactoring - 12 Tool Support for Refactoring • Refactorings: standard re-structurings to solve common problems – Can do them by hand – Put might be tricky • IDEs and separate tools support this – IntelliJ, ReSharper, JRefactory, C# Refactory – Eclipse, JBuilder, next release of Visual Studio Refactoring - 13 Reminder • Refactorings are often small changes – This are low-level design or code level mods Refactoring - 14 Why tools? Ponder these: • In Java, you decide to change a class’s name. What needs to changed? • In Java, you want to change the name of a method. What needs to be changed? Refactoring - 15 Java Refactorings in Eclipse • See help info in Eclipse. And Gallardo article. • Renaming resources – classes, methods, fields – moving to another package – inner and anonymous classes • Class hierarchy modifications – includes make an interface from a class • Code level mods – make a code segment a function Refactoring - 16