Refactoring is a disciplined approach to restructuring code without altering its external behavior, often through small, incremental changes that collectively improve design. It addresses issues like technical debt and promotes better adaptability in response to new requirements while avoiding high risks associated with larger rewrites. Effective refactoring enhances maintainability and reduces complexity, ultimately supporting better software integrity and lower long-term costs.

3. 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.“

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

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

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

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

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

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

10. ?
?
?
?
?
?
?
?
?
?

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

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

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

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

20. Where are hardcoded replicas?

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

22. You will never stop fixing that

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

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

25. Bad habits

26. perpetual
Changes very quickly and accelerates !

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

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

29. Example:
2 cells Clean Architecture

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

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

32. A mess is always a loss.”

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

34. Agile Design
Refactor

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

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

37. Motion
Defects
Overproduction

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

39. Fragility
Lack of separation of concerns, feature envy

40. Extra complexity, effort

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

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

44. Refactoring is a fundamental product survival practice

45. Info

46. Questions ?