1 / 16

CS494: Intro. to Refactoring

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

hammett-maxwell
Download Presentation

CS494: Intro. to Refactoring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. Overview • Refactoring: what and why • Reminders: TDD and Unit Testing • Tool support • (Later: lab exercise)

  3. What Is Refactoring? • Definition: • The process of changing software in a way that the external behavior is not alteredbut 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

  4. 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

  5. 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).

  6. 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 re-verify the design changes again? • What we need to make refactoring successful is • Unit tests

  7. Reminder slides • Remember unit tests? TDD?

  8. 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

  9. 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 loosely-coupled modules to make unit testing easier

  10. 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

  11. 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.

  12. 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/SmellsToRefactorings

  13. 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

  14. Reminder • Refactorings are often small changes • This are low-level design or code level mods

  15. 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?

  16. 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

More Related