1. Refactoring as a Lifeline : Lessons Learned from Refactoring Amr Noaman Abdel-Hamid Software Engineering Competence Center ( SECC ) IT Indeustry Development Agency ( ITIDA ) 2013 IEEE Agile Conference Speaker : 方琮貿 Student number : 102522091

2. Abstract Refactoring legacy code can be a major impediment for team. Due to the high cost of manual regression testing. Also, attempts to implement automated tests. They present a new approach to refactor code that has more sustanable pace of development by continuous refactoring techniques.

3. The Refactoring Approach ( Tradition ) Initial refactoring approach consisted of two high level. Write system/function automated test to enable safe refactoring. Identify design pattern, architectural layers or any best practices.

4. Context of Product The products are live and receive bug reports. The products are 5-10 years. Team size are 6-8 including developers and testers. Teams feel the pain of fixing bugs. Tester uncover many bugs every time they test, even if they were testing unchanged code.

5. Key Observation Objective of refactoring were vague. Automated tests are not the first step. Unsustainable development pace. Management involvement in planning and tracking. The technical glut trap.

6. A better approach ( slow and sure ) Quick wins Remove dead code. Remove code duplicates. Apply homogeneous. Divide & Conquer Discover & split code into components. Enhance component interfaces. Build Quality In Cover components with automated tests. Make components self-testing. Code to be refactor-able simple continuous least risky sustainable.

7. Quick Wins Dead code Dead code increases code size without adding any value. It needs more maintenance. Code duplicates Increase the regression bugs. Time to locate bugs.

8. Quick wins In remove code duplicates, we just need to extract/move methods. Homogeneous Writing a piece of code using different coding style makes it difficult to read.

9. Divide and Conquer Discover components in the code. Pull them out to be standalone and reusable.

10. Separate classes into components Functional components. Architectural components. Serves as part of an architectural pattern. Utility components. Redundant code which are used heavily.

11. Detect and resolve violations Decrease high coupling and backdoor access. Using only simple refactorings Move class Extract/move method Encapsulate field Move field

12. Enhance Components Interfaces Reducing the number of interface methods per component. Reducing the number of parameters. Turned unneeded public method to private. Move methods across components

13. Important roles Refactoring are coded into the product mainline. Not acceptable to branch the code and merge it later. Team should not apply any refactorings. Technical glut trap!! The stage can overlap. Need more time and cost.

14. Conclusion Critical refactoring or rewrite were not allowed. ( Slow but sure ) Introducing component test with excellent code coverage. Bad unstructured code -> semi-structured and testable code. Extremely difficult refactoring may be carried out safely and easily with good tools.

15. Thank you ~