presentation refactoring large legacy applications
TRANSCRIPT
© 2015 Nunsys
Refactoring long-living legacy applications
Manuel Alagarda Esteve
Consultor Business Software
© 2015 Nunsys
A few things about me
Jorge Capel PlanellsConsultor Business Software at NUNSYS
@jcapelplanells
© 2015 Nunsys
The Life path of a long-living application
Una evolución poco sostenible hoy, un sistema inviable mañana.
Infeasibility Stage
Sibylle Peter, Sven Ehrke, Canoo Engineering AG, www.canoo.com
http://www.methodsandtools.com/archive/archive.php?id=98
Do you have a legacy application problem?
• Are you working in a critical application for your business or Company?
• Does your company grow faster than your application?
• Is your application able to achieve business goals in time?
• Do you spend a lot of time and effort working in a new feature?
• Could a simple change take weeks?
• Do you invest a lot of time and effort fixing bugs?
• Do you have a safety net of automated regression tests ?
• Deliver a new version makes your heart sink?
Yes, you have a problem
Infeasibility application
….hero work
Why do you have a legacy problem?
© 2015 Nunsys
Refactor or Rewrite??
Factores en los que nos basamos para tomar a esta decisión
Refactoring
“Refactoring is the process of changing a software system in such a way that it does not alter theexternal behavior of the code yet improves its internal structure.”
Refactoring: Improving the Design of Existing CodeMartin Fowler
Key factors
1 Time to market
2 Continuous changes
3 Techical debt
4 Application size
5 Complexity
6 Cost of application redesign
Refactor or Rewrite??
Technical debt
Changes
Time-to-market
Size
Complex
Cost new application
Refactor o Rewrite?
REESCRIBIR
High technical debt
Low cost of new application
REWRITE
Technical debt 9
Changes 9
Time-to-market 10
Size 1
Complex 1
Cost of new application 3
Refactor or Rewrite?
Technical debt
Changes
Time-to-market
Size
Complexity
Cost of new application
Refactor o rewrite?
REFACTOR
Always refactor with low
technical debt
Technical debt 2
Changes 9
Time-to-market 10
Size 7
Complex 8
Cost of new application 8
Refactor or Rewrite?
Technical debt
Changes
Time-to-market
Size
Complex
Cost of new application
Refactor or Rewrite?
Very high Technical debt
Low changes
Technical debt 8
Changes 2
Time-to-market 2
Size 5
Complex 5
Cost of new application 5
Refactor or Rewrite?
Technical debt
Changes
Time-to-market
Size
Complex
Cost of new application
Refactor or Rewrite?
REFACTORTechnical debt 6
Changes 10
Time-to-market 10
Size 10
Complex 8
Cost of new application 10
© 2015 Nunsys
Case study
Técnicas especificas de un proyecto de refactorización
o Multinational car rental company located in 8 countries
o With its own IT departament and development team
o This team maintains and develops Company’s software
assets
o Software asset under study is a desktop application
8 years old
Aprox. 3,000,000 lines of code
Installed in 200 Workstation
300 users
A case study
o Deliver new functionality to production every 2 weeks
o Plenty of showstopper bugs in production
o At least two hotfixes for each release
o We spend at least 20 percent of our time each iteration fixing production bugs
o High time to market
o High risk of failure. High cost of defects
o No automated tests
o No testing process
State
© 2015 Nunsys
Prerequisites for succesful Refactoring Projects
Condiciones y tareas previas requeridas para poder dar comienzo con un proyecto de refactorización
Management support
Management support is vital to success
• Understand the value of investing in legacy systems is difficult.
• We have to invest more time and money in an application that after allit works as required
• It’s an opportunity to explain what improvements can help your business achieve.
Numbers - ROI
0
5000
10000
15000
20000
25000
30000
0 50 100 150 200 250 300 350 400 450
Cost
Features
Total cost per features
No refactor Refactoring Rewrite
Cost
Refactoring 5.000
Rewrite 15.000
Cost/Feauture
Without
Refactor 60
Refactoring 30
Rewrite 10
Refactoring master plan
ASSESSMENT PERIOD
•Investigate the reasons for the deteriorated state of the application
•Identify differentiators areas that constantly change
•Identify differentiators areas that are critical for business achieve
•Identify areas that changes are expensive
Refactoring master plan
GOALS
•A clear separation between layers
•Clean up the presentation layer
•Replace GUI framework
Refactoring master plan
METRICS
• Quality KPI’s(Technical debt, cyclomatic complexity,cohesion,…)
• Tools: Sonar, Understand,…
Define own KPI’s
•Cost per feature
•Cost per defect
•DRE (Defect removal efficiency)
Team
Trained and experienced
professionals
…and with the resources
needed
Iterative and incremental development
Project must have its own team refactoring “Refactor team”
“Refactor team” must not develop new features
PREPARATORY PHASE IMPLEMENTATION PHASE
User
cases
Master
Plan
Design Parallel Tests
tool
Iteration 0
Analysis Refactor Refactor P.T
Validaton Iteraction 1
Analysis Refactor Refactor PP
Validation Iteration n
Analysis Refactor Refactor PP
Validación
Version control and continuos integration
RELEASE
REFACTORING
trunk
RAMA FUNCIONALIDAD NUEVA
Versión probadaTested version
New feature branch
Custom framework and working method
•Standard development guide
–SOLID
–CLEAN CODE
•Define application architecture
•Use adequate technologies
•Use frameworks
Test automation
• Automate more critical user cases with Functional GUI Testing automation
• Parallel testing “Pruebas paralelas”
© 2015 Nunsys
Main problems
Técnicas especificas de un proyecto de refactorización
© 2015 Nunsys
How can I extract the knowledge?
Reverse engineering
Reverse engineering
Flow diagrams
© 2015 Nunsys
Where should I Start?
Mikado Method
Technique used to identify and to plan refactoring tasks
Mikado Method
Let’s do it
Our process
© 2015 Nunsys
I can´t do it in only one iteration
I can´t do it in only one iteration
Branch by abstraction
Starting point
?????
Final implementation
© 2015 Nunsys
I’ Cant test the legacy application
© 2015 Nunsys
Testing legacy applications
Evitar errores mediante la automatización de pruebas
Parallel Testing
• It’s an “integration test” that runs twice with differents versions• Reference version (code before refactoring)
• Refactor version (code after refactoring)
• Test must be designed to execute a critical process against a high data volumen. Test must cover all critical paths
• Two executions are independents and each one access to a identical DB.
• Finally DBs are compared in order to look for differences
Parallel Testing
Parallel Testing
Which version is our reference?
RELEASE
REFACTORING
trunk
RAMA FUNCIONALIDAD NUEVA
Versión probadaTested version
New feature branch
Functional GUI Testing automation
https://www.youtube.com/watch?v=JzAvIrk6uVI
https://www.youtube.com/watch?v=ciDVHebNphc&list=PLEBB611A728FE430E
Demostración
More info about refactoring
Refactoring: Improving the Design of Existing Code – Martin Fowler
Working Efectivelly with Legacy Code - Michael Feathers
https://sourcemaking.com/refactoring