Agile korea 2013 유석문
Download as PPTX, PDF5 likes2,368 views
This document discusses refactoring, which involves restructuring existing code without changing its external behavior or functionality. It provides definitions of refactoring and describes best practices for refactoring code, such as taking small, incremental steps and verifying that automated tests still pass after each change. Specific refactoring techniques are also explained, like extracting duplicate code into methods, removing unnecessary complexity or duplication, and consolidating conditional expressions for clarity. The document cautions against fixing bugs during refactoring and emphasizes making changes in a way that simplifies the code and removes code smells.
Agile korea 2013 유석문
- 1. 삶이 편해지는 쉬운 리팩토링(Refactoring) 유석문
- 3. What is Refactoring? A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. — Refactoring, Martin Fowler, page 53. Refactoring typically involves • Removing duplicated or dead code • Simplifying complex code • Clarifying unclear code
- 4. Refactoring is revision All good writing is based upon revision. — Jacques Barzun, Simple & Direct, 4th Edition Revision means to re-see or see again.
- 5. How to Refactor The secret to successful refactoring is to take baby steps. When refactoring, your ultimate goal is not to: • break anything • make things worse • introduce new behavior
- 6. How to Refactor • Verify that all automated tests (unit tests) pass • Decide what code to change • Implement one or more refactorings carefully • Run the unit tests whenever you wish to confirm that changes ha ve not altered system behavior • Repeat until the refactoring is complete or revert to an earlier state
- 8. A Chicken and Egg Problem? Many people, when they first encounter the concept of unit testing and refactoring legacy code, consider it a chicken-and-egg conundrum: Can't do one without having the other. Unit Testing Refactoring
- 9. Start with the Universals Always start refactoring work with the three universals. 1. Reformat and Commit. Establish a baseline for later diffs. 2. Eliminate the Noise. A refactored file always minimizes noise and m aximizes signal. 3. Get To Testability. We're going to need some tests. Can we even st art to test our class?
- 10. Consolidate Conditional Expression Clarity "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler, Refactoring
- 11. Extract Hierarchy Highly Cohesive Methods do only one thing and classes have a single, clear responsibility.
- 12. Extract Superclass Duplication Free A program should express each idea once and only once. Code may not always appear to be identical and yet may be expressing the same logic and information. Duplicate code may diverge to become out of sync
- 13. Hide Method Encapsulated A form of information hiding, code that is encapsulated does not expose data or behavior that should be invisible
- 14. Inline Method Simple Code reflects the shortest path to a solution and incorporates only enough complexity to handle its known responsibilities. Simple code is easier to maintain and evolve.
- 15. Caller Creates When you need to create a new class or method that will be invoked by a caller, don't perform the creation where the new code will reside (e.g. in a new file or within the class that will contain the new method). Instead, declare the to-be-created class/method where it will be used, i.e. in the caller code. This will allow you to use IDE tools to automatically generate the exact co de needed by the client, instead of retrofitting client code to the new class/ method after creation.
- 17. Rejected Parameter To avoid passing a parameter to code you want to extract, you must first rej ect the parameter from the extraction. The video on the next page presents three different ways to reject a parameter: 1. Inline the unwanted parameter. 2. Move the unwanted parameter out of the extraction block. 3. Turn the unwanted parameter into a field so it can be referenced from t he extracted method instead of being passed as a parameter.
- 18. Move (Caller Swap) Move responsibilities from a caller to a parameter by calling the parameter with the original caller as its parameter.
- 19. Encapsulated Dependency Before moving code to a new class, first encapsulate dependencies, like fields.
- 20. Remove Duplication by Extract Method - Before
- 21. Remove Duplication - After
- 22. Sample
- 23. Removing A Long Method Smell
- 24. Removing A Long Method Smell (Composed Method)
- 27. Change hierarchy A Map holds keys and values, whereas List and Set just hold objects.
- 28. Duplicated Fields & Methods Duplicated Fields & Methods in List and Set AbstractCollection's method, addAll(...), contains the smells Long Method, Duplicated Code , Switch St atement and Alternative Classes With Different Interfa ces
- 29. Duplicated Fields & Methods
- 30. Don’t Fix Bugs during Refactoring A List should allow duplicates, yet in AbstractCollection your addAll(...) method is checking whether the element is already contained before adding it. There is a time and place to fix bugs and it is not during refactoring.
- 31. Primitive Obsession In Map Map suffers from the Primitive Obsession smell because it wastes too much code manipulating the keys and values arrays.
- 32. Scaffolding Builders make changes to buildings by first putting up scaffolding to make their workea sier and safer. Extract Method refactoring to produce: getValueAt(...) setValueAt(...) When you no longer need your scaffolding, you can remove it by applying the Inline Method refactoring.
- 33. A Temporary Field In Map Map has a field called indexWhereKeyFound that is a p rime example of the Temporary Field Smell.
- 34. Thank you.