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.

Big code refactoring with agility

1,249 views

Published on

How do you handle big code refactoring with Agile methodologies.

Published in: Software

Big code refactoring with agility

  1. 1. HOW DO YOU HANDLE BIG REFACTORING WITH AGILE METHODOLOGIES? Luca Merolla
  2. 2. What is code refactoring?
  3. 3. CODE REFACTORING “Process to change the existing code without changing its external behavior. Refactoring improves nonfunctional attributes of the software”
  4. 4. Why we need code refactoring?
  5. 5. WHY REFACTORING? Some arguments : ❏ Quality ❏ Code Clean ❏ Better Design ❏ Right Thing
  6. 6. WHY REFACTORING? Some arguments : ❏ Quality ❏ Code Clean ❏ Better Design ❏ Right Thing Good Luck!
  7. 7. WHY REFACTORING? The only “sellable” reason to do refactoring is
  8. 8. WHY REFACTORING? The only “sellable” reason to do refactoring is
  9. 9. WHY REFACTORING? The only “sellable” reason to do refactoring is Save money Faster to deliver new functionalities
  10. 10. WHY REFACTORING?
  11. 11. When to do refactoring?
  12. 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. 13. WHEN REFACTORING? Don’t clean up everything. It should be a constant and gradual improvement
  14. 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. 15. How to do refactoring? <
  16. 16. HOW TO REFACTOR? From the methodology point of view, my experience tells me that: ❏ Revolutionary design is evil ❏ Evolutionary design is good
  17. 17. HOW TO REFACTOR? The most common approaches about refactoring are: ❏ “Big Bang” ❏ “Divide and Conquer” ❏ Planned refactoring
  18. 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. 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. 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. 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. 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. 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. 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. 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. 26. How much refactoring should we be doing? <
  27. 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. 28. How can we obtain Refactoring with Agile Methodologies?
  29. 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. 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. 31. VISION Where to go MUST be clear.
  32. 32. Small Steps (Tasks) are easier to handle
  33. 33. Iterate and Learn throughout the process
  34. 34. Which Tools and Techniques should we use?
  35. 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. 36. What is Trunk Based Development?
  37. 37. TRUNK BASED DEV. Branches act as an Isolation from the “real world”.
  38. 38. TRUNK BASED DEV. Multi branches can make the code undeployable for long periods ● Undeployable ● Deployable
  39. 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. 40. TRUNK BASED DEV. How does TBD look like?
  41. 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. 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. 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. 44. What is Branch By Abstraction?
  45. 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. 46. BRANCH BY ABSTRACTION ⇒ ⇒
  47. 47. What are feature toggles/flags?
  48. 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. 49. THANK YOU! Questions? @lucamerolla

×