refactoring as a lifeline : lessons learned from refactoring
Post on 23-Feb-2016
31 Views
Preview:
DESCRIPTION
TRANSCRIPT
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 ~
top related