Successfully reported this slideshow.

Introduction to Refactoring


Published on

Presentation given on 04 Oct 2009 at Barcamp PP2

Published in: Education, Technology, Spiritual
  • Be the first to comment

Introduction to Refactoring

  1. 1. Introduction to Refactoring<br />
  2. 2. About Me<br />VorleakChy<br />Email (<br />Yoolk Inc. (<br />Blog (<br />Rails Developer<br />.NET Developer<br />
  3. 3. What do we talk about Refactoring?<br />What? <br />Why? <br />When? <br />How? <br />
  4. 4. Get Agile – Refactoring<br />Practices<br />Tools<br />
  5. 5. What is Refactoring?<br />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.<br />Fowler, et al., Refactoring, 1999.<br />
  6. 6. Before<br />After<br />Easier to understand<br />Clean code<br />Better code<br />Cheaper to modify<br />… More<br />Unreadable code<br />Duplicated code<br />Complex code<br />Hard to modify<br />… More<br />
  7. 7. Why do we Refactor?<br />The reality<br />Extremely difficult to get the design “right” the first time<br />Hard to fully understand the problem domain<br />Hard to understand user requirements, even if the user does!<br />Hard to know how the system will evolve in five years<br />Original design is often inadequate<br />System becomes brittle over time, and more difficult to change<br />
  8. 8. Why do we Refactor? (Cont.)<br />Helps us to deliver more business values faster<br />Improve code structure and design<br />Easier to maintain and understand<br />Easier to modify<br />More flexibility<br />Easier to add new features<br />Increased re-usability<br />
  9. 9. Why do we Refactor?(Cont.)<br />Keep development at speed<br />To make the software easier to understand<br />Write for people, not the compiler<br />Understand unfamiliar code<br />To help us find bugs<br />Refactor while debugging to clarify the code<br />
  10. 10. Readability<br />Which code segment is easier to read?<br />Sample 1<br />if (date.before(Summer_Start) || date.after(Summer_End))<br /> charge = quantity * winterRate + winterServiceCharge;<br />else<br /> charge = quantity * summerRate;<br />Sample 2<br />if (isSummer(date))<br /> charge = summerCharge(quantity);<br />else<br /> charge = winterCharge(quantity);<br />
  11. 11. When should werefactor?<br />Add new features<br />Fix bugs<br />During code review<br />Only refactor when refactoring. Do not add features during refactoring<br />
  12. 12. When Not to Refactor<br />Sometimes you should throw things out and start again<br />Sometimes you are too close to a deadline<br />
  13. 13. Costs of Not Refactoring<br />Bad code usually takes more code to do the same thing often because of duplication<br />
  14. 14. How do we Refactor?<br />We looks for Code-Smells<br />Things that we suspect are not quite right or will cause us severe pain if we do not fix<br />
  15. 15. Common Code Smells<br />Duplicated code<br />Feature Envy<br />Comments<br />Long Method<br />Long parameter list<br />Switch Statements<br />
  16. 16. Duplicated code<br />There is obvious duplication<br />Such as copy and paste<br />There are unobvious duplications<br />Such as parallel inheritance hierarchies<br />Similar algorithms<br />Remedy<br />Extract Method<br />Pull Up Field<br />
  17. 17. Feature Envy<br />A method that seems more interested in some other classes than the one it is in<br />Remedy<br />Move Method<br />Extract Method<br />
  18. 18. Extract Method<br />void printOwning(double amount){<br />printBanner();<br /> // print details<br />System.Console.WriteLine(string.Format(“name: “, name);<br />System.Console.WriteLine(string.Format(“amount: “, amount);<br />}<br />void printOwning(double amount){<br />printBanner();<br />printDetails(amount);<br />}<br />void printDetails(double amount){<br />System.Console.WriteLine(string.Format(“name: “, name);<br />System.Console.WriteLine(string.Format(“amount: “, amount);<br />}<br />
  19. 19. Comments<br />Comments – be suspicious!<br />Comments represent a failure to express an idea in the code<br />Remedy<br />Extract Method<br />Rename Method<br />
  20. 20. Long Method<br />Good OO code is easiest to understand and maintain with shorter methods with good names<br />Long methods tend to be harder to read and understand<br />Remedy<br />Extract Method<br />Replace Temp with Query<br />Replace Method with Method Object<br />Decompose Conditional<br />
  21. 21. Replace Temp with Query<br />double basePrice = _quanity*<br /> _itemPrice;<br />if(basePrice&gt; 1000) {<br /> return basePrice * 0.95;<br />}<br />else {<br /> return basePrice * 0.98;<br />}<br />if(getBasePrice() &gt; 1000) {<br /> return getBasePrice() * 0.95;<br />}<br />else {<br /> return getBasePrice() * 0.98;<br />}<br />double getBasePrice() {<br /> return _quanitiy * _itemPrice;<br />}<br />
  22. 22. Long parameter list<br />Functions should have as few parameters as possible<br />Remedy<br />Replace Parameter with Method<br />Preserve Whole Object<br />Introduce Parameter Object<br />
  23. 23. Introduce Parameter Object<br />Customer<br />Customer<br />amountInvoicedIn(Date start, Date end)<br />amountRecivedIn(Date start, Date end)<br />amountOverdueIn(Date start, Date end)<br />amountInvoicedIn(DateRangerange)<br />amountRecivedIn(DateRangerange)<br />amountOverdueIn(DateRangerange)<br />
  24. 24. Switch Statements<br />Type cases are evil because they tend to be duplicated many times<br />Remedy<br />Replace Type Code with Subclasses<br />Replace Type Code with State / Strategy<br />Replace Conditional with Polymorphism<br />Replace Parameter with Explicit Methods<br />Introduce Null Object<br />
  25. 25. Replace Parameter with Explicit Methods<br />void setValue(String name, int value)<br />{<br /> if(name.Equals(“height”))<br /> {<br />_height = value;<br />return;<br /> }<br /> if(name.Equals(“width”))<br /> {<br /> _width = value;<br /> return;<br /> }<br />}<br />void setHeight(intvalue)<br />{<br /> _height = value;<br />}<br />void setWidth(intvalue)<br />{<br /> _width = value;<br />}<br />
  26. 26. Refactoring Cycle<br />Choose on appropriate Refactoring to apply<br />Apply Refactoring<br />Run ALL Tests (Get GREEN Bar)<br />Reached Desired Structure?<br />No<br />Yes<br />
  27. 27. Demo <br />
  28. 28. Q & A<br />
  29. 29. Essential Reading<br />
  30. 30. Thank you!<br />