Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Strategic refactoring. Refactoring strategies


Published on

What are your strategies for using refactoring?
How should I start when I face a Big Mess?
What are the generic emergencies for refactoring and why should be considered?
What are the worst case scenarios related to technical debt refactoring and what skills could help?
How refactoring could help eliminate waste (~Lean Development). Clean code, refactoring and technical debt management could address some significant sources of waste as defects, waiting and overproduction. Ward Cunningham's original concept of technical debt refactoring could be used to achieve an adaptive and lean design (that's more than "emergent").
Avoid and manage the technical debt using Disciplined Agile strategies during the end-to-end development life-cycle.

Published in: Technology
  • Be the first to comment

Strategic refactoring. Refactoring strategies

  1. 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. 2. Why refactoring? Core practice for good code Pay technical debt – mess Adapt design to the new requests Pay technical debt – adapt later
  3. 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. 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. 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. 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. 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. 8. ? ? ? ? ? ? ? ? ? ?
  9. 9. When faced with a hard change, first make it easy
  10. 10. first make it easy See : 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. 11.
  12. 12. See similar discussions on tests : See - The Clean CodeTalks - "Global State and Singletons" , by Misko Hevery
  13. 13. Where are hardcoded replicas?
  14. 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. 15. You will never stop fixing that
  16. 16. fragile Fixed after refactoring Lines of code – dramatically reduced
  17. 17. Work by coincidence Local conventions Hidden conventions Important ! • Refactor & Help developers to avoid these bad habits
  18. 18. Bad habits
  19. 19. perpetual Changes very quickly and accelerates !
  20. 20. more than evolutionary Adaptive Lean Business DNA Delivery Feedback Model Inject Business Protect
  21. 21. most of the technologies are here !
  22. 22. Example: 2 cells Clean Architecture
  23. 23. What change together, should stay together It should stay together that changes together
  24. 24. Stop Producing High Debt ! Waste 15 programmers produce debt, 2 are paying it Avoid Waste Help programmers to produce less debt
  25. 25. A mess is always a loss.”
  26. 26. modifying the program to look as if we had known what we were doing all along Ward Cunningham
  27. 27. Agile Design Refactor
  28. 28. Design inadvertence debt ! You need more samples to extract a good abstraction.
  29. 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. 30. Motion Defects Overproduction
  31. 31. clear location for each responsibility Sherlock’s “mind palace
  32. 32. Fragility Lack of separation of concerns, feature envy
  33. 33. Extra complexity, effort
  34. 34.
  35. 35. Refactor technical debt away identify debt
  36. 36. Refactoring is a fundamental product survival practice
  37. 37. Info
  38. 38. Questions ?