1.
Definition (Martin Fowler)
“Refactoring is a disciplined
technique for restructuring an existing
body of code, altering its internal
structure without changing its
external behavior. “
“…a series of small behavior
preserving transformations. Each
transformation (called a "refactoring")
does little, but a sequence of these
transformations can produce a
significant restructuring. Since each
refactoring is small, it's less likely to
go wrong.“

2.
Why
refactoring?
Core practice for good code
Pay technical debt – mess
Adapt design to the new requests
Pay technical debt – adapt later

3.
Alternatives
Redesign
When we cannot change in small steps
Higher risks
Rewrite
More expensive (usually)
With clear requirements and a much simpler
solution, could be an option

4.
Tactical refactoring
Refactoring
Refactoring - Improving the Design
of Existing Code by Martin Fowler
(with Kent Beck), 2 editions
Clean Code
RobertC. Martin books
Implementation patterns
Kent Beck book

5.
Big Mess – external signs
Symptoms of Rotting Design
(Robert C. Martin )
Rigidity – difficult to change
Fragility – breaks in many places for any change
Immobility – cannot be reused
Viscosity – easier to do the wrong things (hacks)
Waste examples
Time to change, time to fix
Time to read & understand
Time to find features
Many defects

6.
Big Mess – internally
Big size: components,
classes, functions
Big numbers: functions
and data members per
class
“Duplications” ~
Multiplications
Reverse of each
refactoring/clean code
pattern

7.
Big Mess & Tactics
Hundreds of problems,
hundreds of tactics
Context matter
Some problems could have a bigger priority
• Important business-related rules are multiplicated
• Some modules are more important than others
• Some problems generate a bigger fragility

8.
?
?
?
?
?
?
?
?
?
?

9.
When faced with a hard change, first make it easy

10.
first make it easy
See : https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414/
After refactoring
• Change/Test/Debug/Refactor are easier
• Each functional flow has its own data transformation flow
• If …these flows are not sharing an unnecessary global context

11.
https://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html

12.
See similar discussions on tests : http://xunitpatterns.com/Erratic%20Test.html
See - The Clean CodeTalks - "Global State and Singletons" , by Misko Hevery

13.
Where are hardcoded replicas?

14.
What we duplicate
Technical mechanisms
More then “car newer engine vs. old engine”
Could be accepted if offer the same functionality
Increase complexity on change & maintenance
Business/Functionality
A threat to business integrity
IncreasedComplexity & Fragility

15.
You will never stop fixing that

16.
fragile
Fixed after refactoring
Lines of code – dramatically reduced

17.
Work by coincidence
Local conventions
Hidden conventions
Important !
• Refactor & Help developers to avoid these bad habits

18.
Bad habits

19.
perpetual
Changes very quickly and accelerates !

20.
more than evolutionary
Adaptive
Lean
Business DNA
Delivery
Feedback
Model
Inject
Business
Protect

21.
most of the technologies are here !
https://www.martinfowler.com/articles/refactoring-external-service.html

22.
Example:
2 cells Clean Architecture

23.
What change together, should stay together
It should stay together that changes together

24.
Stop Producing High Debt !
Waste
15 programmers produce debt,
2 are paying it
Avoid Waste
Help programmers to produce less debt

25.
A mess is always a loss.”

26.
modifying the program to look as if we had
known what we were doing all along
Ward Cunningham
https://youtu.be/pqeJFYwnkjE?t=1

27.
Agile Design
Refactor

28.
Design inadvertence debt !
You need more samples to extract a good abstraction.

29.
Refactoring & Avoiding Waste
Lean Software development
Inspired from
Toyota Production System
Reference:
Lean Software Development:
An AgileToolkit - Mary and
Tom Poppendieck
Solutions: XP-like practices,
refactoring included

30.
Motion
Defects
Overproduction

31.
clear location for each responsibility
Sherlock’s “mind palace

32.
Fragility
Lack of separation of concerns, feature envy

33.
Extra complexity, effort

34.
https://disciplinedagiledelivery.com/essence01/
http://www.agiledata.org/essays/databaseRefactoring.html
http://www.agiledata.org/essays/databaseRefactoringCatalog.html
http://agiledata.org/

35.
Refactor technical debt away
identify debt
https://disciplinedagiledelivery.com/technical-debt/

36.
Refactoring is a fundamental product survival practice

37.
Info

38.
Questions ?