Introduction to Refactoring
Download as PPTX, PDF5 likes1,143 views
This document introduces refactoring and discusses its benefits. Refactoring is defined as changing code without altering external behavior to improve internal structure. It is done to make code easier to understand and modify over time as requirements change. Common reasons for refactoring include fixing code smells like duplicated code, long methods, and comments. The document outlines when to refactor, such as when adding features or fixing bugs, and how to refactor using techniques like extracting methods, replacing temporary variables with queries, and introducing parameter objects. An example refactoring cycle is presented along with essential reading materials on refactoring.
Introduction to Refactoring
- 2. About MeVorleakChyEmail ([email protected])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 – RefactoringPracticesTools
- 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. BeforeAfterEasier to understandClean codeBetter codeCheaper to modify… MoreUnreadable codeDuplicated codeComplex codeHard to modify… More
- 7. Why do we Refactor?The realityExtremely difficult to get the design “right” the first timeHard to fully understand the problem domainHard to understand user requirements, even if the user does!Hard to know how the system will evolve in five yearsOriginal design is often inadequateSystem becomes brittle over time, and more difficult to change
- 8. Why do we Refactor? (Cont.)Helps us to deliver more business values fasterImprove code structure and designEasier to maintain and understandEasier to modifyMore flexibilityEasier to add new featuresIncreased re-usability
- 9. Why do we Refactor?(Cont.)Keep development at speedTo make the software easier to understandWrite for people, not the compilerUnderstand unfamiliar codeTo help us find bugsRefactor while debugging to clarify the code
- 10. ReadabilityWhich code segment is easier to read?Sample 1if (date.before(Summer_Start) || date.after(Summer_End)) charge = quantity * winterRate + winterServiceCharge;else charge = quantity * summerRate;Sample 2if (isSummer(date)) charge = summerCharge(quantity);else charge = winterCharge(quantity);
- 11. When should werefactor?Add new featuresFix bugsDuring code reviewOnly refactor when refactoring. Do not add features during refactoring
- 12. When Not to RefactorSometimes you should throw things out and start againSometimes you are too close to a deadline
- 13. Costs of Not RefactoringBad code usually takes more code to do the same thing often because of duplication
- 14. How do we Refactor?We looks for Code-SmellsThings that we suspect are not quite right or will cause us severe pain if we do not fix
- 15. Common Code SmellsDuplicated codeFeature EnvyCommentsLong MethodLong parameter listSwitch Statements
- 16. Duplicated codeThere is obvious duplicationSuch as copy and pasteThere are unobvious duplicationsSuch as parallel inheritance hierarchiesSimilar algorithmsRemedyExtract MethodPull Up Field
- 17. Feature EnvyA method that seems more interested in some other classes than the one it is inRemedyMove MethodExtract Method
- 18. Extract Methodvoid printOwning(double amount){printBanner(); // print detailsSystem.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. CommentsComments – be suspicious!Comments represent a failure to express an idea in the codeRemedyExtract MethodRename Method
- 20. Long MethodGood OO code is easiest to understand and maintain with shorter methods with good namesLong methods tend to be harder to read and understandRemedyExtract MethodReplace Temp with QueryReplace Method with Method ObjectDecompose Conditional
- 21. Replace Temp with Querydouble 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 listFunctions should have as few parameters as possibleRemedyReplace Parameter with MethodPreserve Whole ObjectIntroduce Parameter Object
- 23. Introduce Parameter ObjectCustomerCustomeramountInvoicedIn(Date start, Date end)amountRecivedIn(Date start, Date end)amountOverdueIn(Date start, Date end)amountInvoicedIn(DateRangerange)amountRecivedIn(DateRangerange)amountOverdueIn(DateRangerange)
- 24. Switch StatementsType cases are evil because they tend to be duplicated many timesRemedyReplace Type Code with SubclassesReplace Type Code with State / StrategyReplace Conditional with PolymorphismReplace Parameter with Explicit MethodsIntroduce Null Object
- 25. Replace Parameter with Explicit Methodsvoid 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 CycleChoose on appropriate Refactoring to applyApply RefactoringRun ALL Tests (Get GREEN Bar)Reached Desired Structure?NoYes
- 27. Demo
- 28. Q & A
- 30. Thank you!