presentation refactoring large legacy applications

© 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

[email protected]

@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

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



Technical debt

Changes

Time-to-market

Size

Complex



Very high Technical debt

Low changes

Technical debt 8

Changes 2

Time-to-market 2

Size 5

Complex 5



Technical debt

Changes

Time-to-market

Size

Complex



REFACTORTechnical debt 6

Changes 10

Time-to-market 10

Size 10

Complex 8


© 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


GOALS

•A clear separation between layers

•Clean up the presentation layer

•Replace GUI framework


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

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

I can´t do it in only one iteration

Branch by abstraction

Starting point

Final implementation

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

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

https://www.youtube.com/watch?v=JzAvIrk6uVI

https://www.youtube.com/watch?v=ciDVHebNphc&list=PLEBB611A728FE430E

More info about refactoring

Refactoring: Improving the Design of Existing Code – Martin Fowler

Working Efectivelly with Legacy Code - Michael Feathers

https://sourcemaking.com/refactoring