How do you handle big code refactoring with Agile methodologies.

1. HOW DO YOU HANDLE
BIG REFACTORING WITH AGILE
METHODOLOGIES?
Luca Merolla

2. What is code refactoring?

3. CODE REFACTORING
“Process to change the existing code without changing
its external behavior.
Refactoring improves nonfunctional attributes
of the software”

4. Why we need code
refactoring?

5. WHY REFACTORING?
Some arguments :
❏ Quality
❏ Code Clean
❏ Better Design
❏ Right Thing

6. WHY REFACTORING?
Some arguments :
❏ Quality
❏ Code Clean
❏ Better Design
❏ Right Thing
Good Luck!

7. WHY REFACTORING?
The only “sellable” reason to do refactoring is

8. WHY REFACTORING?
The only “sellable” reason to do refactoring is

9. WHY REFACTORING?
The only “sellable” reason to do refactoring is
Save money Faster to deliver new
functionalities

10. WHY REFACTORING?

11. When to do refactoring?

12. WHEN REFACTORING?
Ideally, when we identify:
❏ Code Smells: Things are not right
❏ WTFs: Code is not understandable
❏ It should be different: Product evolved

13. WHEN REFACTORING?
Don’t clean up everything.
It should be a constant and
gradual improvement

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

15. How to do refactoring?
<

16. HOW TO REFACTOR?
From the methodology point of view, my experience
tells me that:
❏ Revolutionary design is evil
❏ Evolutionary design is good

17. HOW TO REFACTOR?
The most common approaches about refactoring are:
❏ “Big Bang”
❏ “Divide and Conquer”
❏ Planned refactoring

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

19. 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!
❏ High risks!
❏ Almost like rewrite from scratch

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

21. HOW TO REFACTOR?
The “Divide and Conquer” approach:
❏ Define a Vision
❏ Break the application into pieces
❏ Rebuild the puzzle
❏ Make tests green again!
❏ Difficult estimation (like bugs)
❏ Code could be “undeliverable” for
long period

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

23. 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
❏ It’s a Methodology Smell!
❏ No real “value” added to the
application

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

25. 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)
❏ Code can be delivered (often)
❏ New features benefits from the
refactor (faster to develop)

26. How much refactoring should
we be doing?
<

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

28. How can we obtain
Refactoring with Agile
Methodologies?

29. AGILE & REFACTOR?
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.

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

31. VISION
Where to go MUST be clear.

32. Small Steps
(Tasks) are
easier to
handle

33. Iterate and Learn
throughout
the process

34. Which Tools and Techniques
should we use?

35. TOOLS & TECHNIQUES
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

36. What is Trunk Based
Development?

37. TRUNK BASED DEV.
Branches act as an Isolation from the “real world”.

38. TRUNK BASED DEV.
Multi branches
can make the
code
undeployable
for long
periods
● Undeployable
● Deployable

39. TRUNK BASED DEV.
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

40. TRUNK BASED DEV.
How does TBD look like?

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

42. TRUNK BASED DEV.
F FIX TBD Optimistic Branching
R D ?
R RELEASED
DEVELOPED NO COMMITS YET
D ?
209 210 211 TRUNK
209.x
FIX
R
209.1
R D F
?
209 210 211 TRUNK

43. TRUNK BASED DEV.
TBD Pessimistic Branching
R RELEASED
F FIX DEVELOPED NO COMMITS YET
D ?
209.x
?
R D ?
209 210 211 TRUNK
209.x
R D
R
211.x
?
209 210 211 TRUNK
209.x
R D
FIX
R
209.1
F
R
211.x
?
209 210 211 TRUNK

44. What is Branch By Abstraction?

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

46. BRANCH BY ABSTRACTION
⇒
⇒

47. What are feature toggles/flags?

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

49. THANK YOU!
Questions?
@lucamerolla