Big code refactoring with agility
-
Upload
luca-merolla -
Category
Software
-
view
233 -
download
4
description
Transcript of 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