• Save
Code Refactoring
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Code Refactoring

on

  • 3,786 views

This is an old tutorial I used to give on code refactoring, with thanks to Martin Fowler...

This is an old tutorial I used to give on code refactoring, with thanks to Martin Fowler...

Statistics

Views

Total Views
3,786
Views on SlideShare
3,752
Embed Views
34

Actions

Likes
5
Downloads
0
Comments
0

3 Embeds 34

http://www.linkedin.com 26
https://www.linkedin.com 5
http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Code Refactoring Presentation Transcript

  • 1. Code Refactoring Charlie Berg [email_address]
  • 2. What Is Refactoring
    • Martin Fowler says that 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. "
      • Just cleaning up code.
    • At first, code is pretty good but as requirements change or new features are added, the code structure tends to atrophy. Refactoring is the process of fixing a bad or chaotic design.
    • Amounts to moving methods around, creating new methods, adding or deleting classes, .. .
  • 3. Why Refactor?
    • Fowler says he will refactor existing code just to understand it better and sometimes it helps to find bugs.
    • Improve code structure and design
      • More maintainable
      • Easier to understand
      • Easier to modify
      • Easier to add new features
  • 4. Why Refactor?
    • Improving design includes removing duplicate code.
      • Removes bloat
      • Only want one place to change functionality not multiple.
    • Cumulative effect can radically improve design rather than normal slide into decay.
    • In summary, refactoring helps you develop better code, faster!
  • 5. When to Refactor?
    • Refactor when:
      • You add new features and the code is brittle or hard to understand. Refactoring makes this feature and future features easier to build.
      • You fix bugs.
      • During code review.
    • Alternate code development and refactoring.
    • Only refactor when refactoring--do not add features during refactoring.
  • 6. When Not to Refactor
    • Sometimes you should throw things out and start again.
    • Sometimes you are too close to a deadline.
  • 7. Costs of Not Refactoring
    • Bad code usually takes more code to do the same thing often because of duplication:
  • 8. Refactor Opportunities
    • Duplicated Code:
      • Extract out the common bits into their own method ( extract method ) if code is in same class if two classes duplicate code, consider extract class to create a new class to hold the shared functionality.
    • Long Methods
      • Extract method
    • Large Class
      • Class trying to do too much often shows up as too many instance variables.
  • 9. Refactor Opportunities
    • Long Parameter List
      • Replace parameter with method (receiver explicitly asks sender for data via sender getter method) Example: day month, year, hour minute second ==> date
    • Divergent Change
      • If you have a fixed class that does distinctly different things consider separating out the varying code into varying classes (extract class) that either subclassor are contained by the non-varying class.
  • 10. Refactor Opportunities
    • Shotgun Surgery
      • The smell: a change in one class repeatedly requires little changes in a bunch of other classes. Use move method and move field to get all the bits into one class since they are obviously highly dependent.
    • Feature Envy
      • Method in one class uses lots of pieces from another class. move method to move it to the other class.
  • 11. Refactor Opportunities
    • Data Clumps
      • Data that's always hanging with each other (e.g. name street zip).
      • extract class for the data. Will help trim argument lists since name/street/zip now passed as one address object.
    • Switch (case) statements
      • Use inheritance and polymorphism instead (this is one of the more difficult refactorings)
  • 12. Refactor Opportunities
    • Lazy Class
      • Class doesn't seem to be doing anything. Get rid of it!
      • collapse heirarchy if subclasses are nearly vacuous.
      • inline class (stick the class' methods and fields in the class that was using it and delete original class).
  • 13. Refactor Opportunities
    • Speculative generality
      • Class designed to do something in the future but never ends up doing it. Thinking too far ahead! collapse hierarchy or inline class
    • Message chains
      • To send a message to object D in class A have to go through B to get C and C to get D. Use hide delagate to hide C and D in B, and add a method to B that does what A wanted to do with D.
  • 14. Refactor Opportunities
    • Inappropriate Intimacy
      • Directly getting in and munging with the internals of another class. Use move methods, inline methods , to consolidate the intimate bits.
    • Incomplete Library Class
      • If method missing from library, and can't change the library, either:
        • Make this method in object ( introduce foreign method ) if lots of changes
        • Make your own extension/subclass ( introduce local extension )
  • 15. Refactor Opportunities
    • Data Class
      • In data-centric design, there are some data classes which are pretty much structs: no interesting methods.
      • Don't directly get and set fields (make them private)‏
      • Don't have setter for things outsiders shouldn't change
      • Look who uses the data and how they use it and move code to the data class via a combinationof extract method and move method
    • Comments
      • Comments in the middleof methods are deodorant. Refactor so each comment block is its own method. extract method .
  • 16. Summary
    • Extract method, hide delegate, move methods (bolded above) found in...
      • http://www.refactoring.com/index.html
      • Great refactoring site!!!
    • Martin Fowler:
      • "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."