Big code refactoring with agility

HOW DO YOU HANDLE BIG REFACTORING WITH AGILE

METHODOLOGIES?

Luca Merolla

What is code refactoring?

“Process to change the existing code without changing its external behavior.

Refactoring improves nonfunctional attributes of the software”

CODE REFACTORING

Why we need code refactoring?

Some arguments :

❏ Quality❏ Code Clean❏ Better Design❏ Right Thing

WHY REFACTORING?

Some arguments :

❏ Quality❏ Code Clean❏ Better Design❏ Right Thing

WHY REFACTORING?

Good Luck!

The only “sellable” reason to do refactoring is

WHY REFACTORING?

The only “sellable” reason to do refactoring is

WHY REFACTORING?

The only “sellable” reason to do refactoring is

WHY REFACTORING?

Save money Faster to deliver new functionalities

WHY REFACTORING?

When to do refactoring?

Ideally, when we identify:

❏ Code Smells: Things are not right

❏ WTFs: Code is not understandable

❏ It should be different: Product evolved

WHEN REFACTORING?

Don’t clean up everything.

It should be a constant and gradual improvement

WHEN REFACTORING?

Keep the balance between:refactoring vs new features

Don't refactor unless you think it will pay off later by allowing faster feature delivery

WHEN REFACTORING?

How to do refactoring?<

From the methodology point of view, my experience tells me that:

❏ Revolutionary design is evil

❏ Evolutionary design is good

HOW TO REFACTOR?

The most common approaches about refactoring are:

❏ “Big Bang”

❏ “Divide and Conquer”

❏ Planned refactoring

HOW TO REFACTOR?

The “Big Bang” approach:❏ Define a new structure for your code❏ Move the code to the new structure❏ Rebuild the puzzle❏ Make tests green again!

HOW TO REFACTOR?

The “Big Bang” approach:❏ Define a new structure for your code❏ Move the code to the new structure❏ Rebuild the puzzle❏ Make tests green again!

HOW TO REFACTOR?

❏ High risks!❏ Almost like rewrite from scratch

The “Divide and Conquer” approach:❏ Define a Vision❏ Break the application into pieces❏ Rebuild the puzzle❏ Make tests green again!

HOW TO REFACTOR?

The “Divide and Conquer” approach:❏ Define a Vision❏ Break the application into pieces❏ Rebuild the puzzle❏ Make tests green again!

HOW TO REFACTOR?

❏ Difficult estimation (like bugs)❏ Code could be “undeliverable” for

long period

Planned Refactoring also called as Stabilization periods:❏ No new features developed (Code freeze period)❏ Work without adding Value❏ Not an improvement for the customer

HOW TO REFACTOR?

Planned Refactoring also called as Stabilization periods:❏ No new features developed (Code freeze period)❏ Work without adding Value❏ Not an improvement for the customer

HOW TO REFACTOR?

❏ It’s a Methodology Smell!❏ No real “value” added to the

application

What a Good Team does is:❏ Define a Vision❏ Break it into smaller tasks❏ Refactoring all the time (part of regular work)❏ Responsible (Diligently keep the code clean)

HOW TO REFACTOR?

What a Good Team does is:❏ Define a Vision❏ Break it into smaller tasks❏ Refactoring all the time (part of regular work)❏ Responsible (Diligently keep the code clean)

HOW TO REFACTOR?

❏ Code can be delivered (often)❏ New features benefits from the

refactor (faster to develop)

How much refactoring should we be doing?

<

HOW MUCH REFACTOR?

We need to always consider the benefits of refactoring❏ Tolerance level (metrics could help)❏ Don’t clean up everything❏ Make refactoring part of our daily work❏ Multiple small improvements❏ Don’t refactor what is not likely to change❏ Consider the economic factor:

Cleaner code ⇨ Quicker and Cheaper changes

How can we obtain Refactoring with Agile

Methodologies?

Agile Methodologies focuses on continuous (or at least frequent) Value delivery.

The Value (for the customer) is realized when the product is shipped in production, not before.

AGILE & REFACTOR?

In order to use Agile Methodologies for big refactoring, we need to enforce some practices:

❏ Define and communicate the Vision

❏ Start with small tasks

❏ Iterate and Learn

AGILE & REFACTOR?

VISIONWhere to go MUST be clear.

Small Steps(Tasks) are

easier tohandle

Iterate and Learn throughout the process

Which Tools and Techniques should we use?

There are different tools and techniques that can help us to be more agile and deliver more often:

❏ Trunk Based Development

❏ Branch By Abstraction

❏ Feature Toggles/Flags

TOOLS & TECHNIQUES

What is Trunk Based Development?

Branches act as an Isolation from the “real world”.

TRUNK BASED DEV.

Multi branchescan make the codeundeployable for long periods

TRUNK BASED DEV.

● Undeployable● Deployable

What is really wrong with Branches?

❏ Branching is not bad, long lived branches are bad

❏ “Isolation” for prolonged periods of time is bad

❏ Multi-branches can lead to undeployable code

TRUNK BASED DEV.

How does TBD look like?

TRUNK BASED DEV.

What are the benefits of TBD?❏ Work on a single shared trunk❏ Always work against the latest code❏ Merge and integration pain is minimised

Note:❏ TBD does not prohibit branching

TRUNK BASED DEV.

TRUNK BASED DEV.

TRUNK209 210 211R D ?

TRUNK209 210 211R D ?

209.xFIX

R

209.1

F

D ?

R RELEASED

DEVELOPED NO COMMITS YET

F FIXTBD Optimistic Branching

TRUNK BASED DEV.

D ?

R RELEASED

DEVELOPED NO COMMITS YET

F FIXTBD Pessimistic Branching

TRUNK209 210 211R D

209.x

TRUNK209 210 211R D

209.xFIX

R

209.1

F

TRUNK209 210 211R D ?

209.x?

R

211.x?

R

211.x?

What is Branch By Abstraction?

BRANCH BY ABSTRACTION

1. Introduce an abstraction layer

2. Update all the code to rely on the abstraction

3. Make new implementation of the abstraction

4. Remove the old implementation

BRANCH BY ABSTRACTION

⇒

⇒

What are feature toggles/flags?

TOGGLES & FLAGS?

What are the advantages of using Feature Toggles:

❏ Decouples code deployment from feature❏ No need to rollback (disable the feature)❏ A/B testing❏ Deliver features to specific users only❏ Continuous delivery

THANK YOU!

@lucamerolla

Questions?