Introduction to Refactoring

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

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

Get Agile – RefactoringPracticesTools

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.

BeforeAfterEasier to understandClean codeBetter codeCheaper to modify… MoreUnreadable codeDuplicated codeComplex codeHard to modify… More

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

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

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

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);

When should werefactor?Add new featuresFix bugsDuring code reviewOnly refactor when refactoring. Do not add features during refactoring

When Not to RefactorSometimes you should throw things out and start againSometimes you are too close to a deadline

Costs of Not RefactoringBad code usually takes more code to do the same thing often because of duplication

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

Common Code SmellsDuplicated codeFeature EnvyCommentsLong MethodLong parameter listSwitch Statements

Duplicated codeThere is obvious duplicationSuch as copy and pasteThere are unobvious duplicationsSuch as parallel inheritance hierarchiesSimilar algorithmsRemedyExtract MethodPull Up Field

Feature EnvyA method that seems more interested in some other classes than the one it is inRemedyMove MethodExtract Method

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);}

CommentsComments – be suspicious!Comments represent a failure to express an idea in the codeRemedyExtract MethodRename Method

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

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;}

Long parameter listFunctions should have as few parameters as possibleRemedyReplace Parameter with MethodPreserve Whole ObjectIntroduce Parameter Object

Introduce Parameter ObjectCustomerCustomeramountInvoicedIn(Date start, Date end)amountRecivedIn(Date start, Date end)amountOverdueIn(Date start, Date end)amountInvoicedIn(DateRangerange)amountRecivedIn(DateRangerange)amountOverdueIn(DateRangerange)

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

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;}

Refactoring CycleChoose on appropriate Refactoring to applyApply RefactoringRun ALL Tests (Get GREEN Bar)Reached Desired Structure?NoYes

Demo

Q & A

Essential Reading

Thank you!