Refactoring as a Lifeline :Lessons Learned from Refactoring

Amr Noaman Abdel-HamidSoftware Engineering Competence Center ( SECC )IT Indeustry Development Agency ( ITIDA )

2013 IEEE Agile Conference

Speaker : 方琮貿Student number : 102522091

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.

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.

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.

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.

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.

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.

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.

Divide and Conquer• Discover components in the code.

• Pull them out to be standalone and reusable.

Separate classes into components• Functional components.

• Architectural components.• Serves as part of an architectural pattern.

• Utility components.• Redundant code which are used heavily.

Detect and resolve violations• Decrease high coupling and backdoor access.

• Using only simple refactorings• Move class• Extract/move method• Encapsulate field• Move field

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

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.

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.

Thank you ~