Presentation refactoring large legacy applications

1. © 2015 Nunsys
Refactoring long-living legacy applications
Manuel Alagarda Esteve

2. © 2015 Nunsys
A few things about me
Jorge Capel Planells
Consultor Business Software at NUNSYS
Jorge.capel@nunsys.com
@jcapelplanells

3. © 2015 Nunsys
The Life path of a long-living application
Una evolución poco sostenible hoy, un sistema inviable mañana.

4. Infeasibility Stage
Sibylle Peter, Sven Ehrke, Canoo Engineering AG, www.canoo.com
http://www.methodsandtools.com/archive/archive.php?id=98

5. 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?

6. Yes, you have a problem

7. Infeasibility application
….hero work

8. Why do you have a legacy problem?

9. © 2015 Nunsys
Refactor or Rewrite??
Factores en los que nos basamos para tomar a esta decisión

10. Refactoring
“Refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code yet improves its internal structure.”
Refactoring: Improving the Design of Existing Code
Martin Fowler

11. Key factors
1 Time to market
2 Continuous changes
3 Techical debt
4 Application size
5 Complexity
6 Cost of application redesign

12. 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

13. 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

14. 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

15. Refactor or Rewrite?
Technical debt
Changes
Time-to-market
Size
Complex
Cost of new application
Refactor or Rewrite?
REFACTOR
Technical debt 6
Changes 10
Time-to-market 10
Size 10
Complex 8
Cost of new application 10

16. © 2015 Nunsys
Case study
Técnicas especificas de un proyecto de refactorización

17. 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

18. 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

19. © 2015 Nunsys
Prerequisites for succesful Refactoring Projects
Condiciones y tareas previas requeridas para poder dar comienzo con un proyecto de
refactorización

20. 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 all
it works as required
• It’s an opportunity to explain what improvements can help your
business achieve.

21. 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

22. 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

23. Refactoring master plan
GOALS
•A clear separation between layers
•Clean up the presentation layer
•Replace GUI framework

24. 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)

25. Team
Trained and experienced
professionals
…and with the resources
needed

26. 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

27. Version control and continuos integration
RELEASE
REFACTORING
trunk
RAMA FUNCIONALIDAD NUEVA
Versión probadaTested version
New feature branch

28. Custom framework and working method
•Standard development guide
–SOLID
–CLEAN CODE
•Define application architecture
•Use adequate technologies
•Use frameworks

29. Test automation
• Automate more critical user cases with Functional GUI Testing
automation
• Parallel testing “Pruebas paralelas”

30. © 2015 Nunsys
Main problems
Técnicas especificas de un proyecto de refactorización

31. © 2015 Nunsys
How can I extract the knowledge?

32. Reverse engineering

33. Reverse engineering

34. Flow diagrams

35. © 2015 Nunsys
Where should I Start?

36. Mikado Method
Technique used to identify and to plan
refactoring tasks

37. Mikado Method

38. Let’s do it

40. Our process

41. © 2015 Nunsys
I can´t do it in only one iteration

42. I can´t do it in only one iteration

43. Branch by abstraction

44. Starting point

45. ?????

46. Final implementation

47. © 2015 Nunsys
I’ Cant test the legacy application

48. © 2015 Nunsys
Testing legacy applications
Evitar errores mediante la automatización de pruebas

49. 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

50. Parallel Testing

51. Parallel Testing

52. Which version is our reference?
RELEASE
REFACTORING
trunk
RAMA FUNCIONALIDAD NUEVA
Versión probadaTested version
New feature branch

53. Functional GUI Testing automation
https://www.youtube.com/watch?v=JzAvIrk6uVI
https://www.youtube.com/watch?v=ciDVHebNphc&list=PLEB
B611A728FE430E
Demostración

54. More info about refactoring
 Refactoring: Improving the Design of Existing Code – Martin Fowler
 Working Efectivelly with Legacy Code - Michael Feathers
 https://sourcemaking.com/refactoring