Your SlideShare is downloading. ×
Code Refactoring
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Code Refactoring

3,034
views

Published on

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

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,034
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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