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