Presentation given on 04 Oct 2009 at Barcamp PP2

1. Introduction to Refactoring

2. About Me VorleakChy Email (vorleak.chy@gmail.com) Yoolk Inc. (http://www.yoolk.com) Blog (http://vorleakchy.com) Rails Developer .NET Developer

3. What do we talk about Refactoring? What? Why? When? How?

4. Get Agile – Refactoring Practices Tools

5. What is Refactoring? 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. Fowler, et al., Refactoring, 1999.

6. Before After Easier to understand Clean code Better code Cheaper to modify … More Unreadable code Duplicated code Complex code Hard to modify … More

7. Why do we Refactor? The reality Extremely difficult to get the design “right” the first time Hard to fully understand the problem domain Hard to understand user requirements, even if the user does! Hard to know how the system will evolve in five years Original design is often inadequate System becomes brittle over time, and more difficult to change

8. Why do we Refactor? (Cont.) Helps us to deliver more business values faster Improve code structure and design Easier to maintain and understand Easier to modify More flexibility Easier to add new features Increased re-usability

9. Why do we Refactor?(Cont.) Keep development at speed To make the software easier to understand Write for people, not the compiler Understand unfamiliar code To help us find bugs Refactor while debugging to clarify the code

10. Readability Which code segment is easier to read? Sample 1 if (date.before(Summer_Start) || date.after(Summer_End)) charge = quantity * winterRate + winterServiceCharge; else charge = quantity * summerRate; Sample 2 if (isSummer(date)) charge = summerCharge(quantity); else charge = winterCharge(quantity);

11. When should werefactor? Add new features Fix bugs During code review Only refactor when refactoring. Do not add features during refactoring

12. When Not to Refactor Sometimes you should throw things out and start again Sometimes you are too close to a deadline

13. Costs of Not Refactoring Bad code usually takes more code to do the same thing often because of duplication

14. How do we Refactor? We looks for Code-Smells Things that we suspect are not quite right or will cause us severe pain if we do not fix

15. Common Code Smells Duplicated code Feature Envy Comments Long Method Long parameter list Switch Statements

16. Duplicated code There is obvious duplication Such as copy and paste There are unobvious duplications Such as parallel inheritance hierarchies Similar algorithms Remedy Extract Method Pull Up Field

17. Feature Envy A method that seems more interested in some other classes than the one it is in Remedy Move Method Extract Method

18. Extract Method void printOwning(double amount){ printBanner(); // print details System.Console.WriteLine(string.Format(“name: “, name); System.Console.WriteLine(string.Format(“amount: “, amount); } void printOwning(double amount){ printBanner(); printDetails(amount); } void printDetails(double amount){ System.Console.WriteLine(string.Format(“name: “, name); System.Console.WriteLine(string.Format(“amount: “, amount); }

19. Comments Comments – be suspicious! Comments represent a failure to express an idea in the code Remedy Extract Method Rename Method

20. Long Method Good OO code is easiest to understand and maintain with shorter methods with good names Long methods tend to be harder to read and understand Remedy Extract Method Replace Temp with Query Replace Method with Method Object Decompose Conditional

21. Replace Temp with Query double basePrice = _quanity* _itemPrice; if(basePrice> 1000) { return basePrice * 0.95; } else { return basePrice * 0.98; } if(getBasePrice() > 1000) { return getBasePrice() * 0.95; } else { return getBasePrice() * 0.98; } double getBasePrice() { return _quanitiy * _itemPrice; }

22. Long parameter list Functions should have as few parameters as possible Remedy Replace Parameter with Method Preserve Whole Object Introduce Parameter Object

23. Introduce Parameter Object Customer Customer amountInvoicedIn(Date start, Date end) amountRecivedIn(Date start, Date end) amountOverdueIn(Date start, Date end) amountInvoicedIn(DateRangerange) amountRecivedIn(DateRangerange) amountOverdueIn(DateRangerange)

24. Switch Statements Type cases are evil because they tend to be duplicated many times Remedy Replace Type Code with Subclasses Replace Type Code with State / Strategy Replace Conditional with Polymorphism Replace Parameter with Explicit Methods Introduce Null Object

25. Replace Parameter with Explicit Methods void setValue(String name, int value) { if(name.Equals(“height”)) { _height = value; return; } if(name.Equals(“width”)) { _width = value; return; } } void setHeight(intvalue) { _height = value; } void setWidth(intvalue) { _width = value; }

26. Refactoring Cycle Choose on appropriate Refactoring to apply Apply Refactoring Run ALL Tests (Get GREEN Bar) Reached Desired Structure? No Yes

27. Demo

28. Q & A

29. Essential Reading

30. Thank you!