Your SlideShare is downloading. ×
0
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
Code Refactoring
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,137

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

×