Refactoring as a Lifeline : Lessons Learned from Refactoring

1. Refactoring as a Lifeline :Lessons Learned from Refactoring Amr Noaman Abdel-HamidSoftware Engineering Competence Center ( SECC )IT Indeustry Development Agency ( ITIDA ) 2013 IEEE Agile ConferenceSpeaker : 方琮貿 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 ) • 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 ComponentsInterfaces • 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 ~