Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Confident refactors

Confident refactors

Mehdi Lahmam B.

June 19, 2017
Tweet

More Decks by Mehdi Lahmam B.

Other Decks in Technology

Transcript

  1. Confident Refactors

    View Slide

  2. Mehdi Lahmam
    @mehlah

    View Slide

  3. 25kV
    Rails app, started in Feb 2009
    Never rewritten
    23k+ commits from 52 contributors

    View Slide

  4. Ruby is a massively
    successful language!

    View Slide

  5. Early success
    Making it easy to make new things

    View Slide

  6. Later success
    Making it easy to maintain old things

    View Slide

  7. Today, let’s refactor
    some legacy code

    View Slide

  8. Today, let’s refactor
    some legacy code

    View Slide

  9. Refactor - verb
    To change the design of code
    without changing its observable behavior.

    View Slide

  10. Refactor - verb
    To change in advance of a new feature
    or bug fix, making the job easier.

    View Slide

  11. Today, let’s refactor
    some legacy code

    View Slide

  12. Legacy - noun
    Old code.

    View Slide

  13. Legacy - noun
    Code without tests.

    View Slide

  14. Legacy - noun
    Code that we don’t like.

    View Slide

  15. Legacy - noun
    Code we don’t understand well enough

    to change confidently.

    View Slide

  16. Today, let’s refactor
    some legacy code

    View Slide

  17. Refactoring is hard

    View Slide

  18. Refactoring legacy code
    is very hard

    View Slide

  19. Easy to accidentally
    break functionality

    View Slide

  20. Legacy refactors
    feels unsafe

    View Slide

  21. Legacy refactors
    are hard to sell

    View Slide

  22. Business priority
    Cost / risks

    View Slide

  23. Business priority
    Cost / risks
    New features

    View Slide

  24. Business priority
    Cost / risks
    New features
    Bugs fixes

    View Slide

  25. Business priority
    Cost / risks
    New features
    Bugs fixes
    Testing

    View Slide

  26. Business priority
    Cost / risks
    New features
    Bug fixes
    Testing Refactoring

    View Slide

  27. Business priority
    Cost / risks
    New features
    Bug fixes
    Testing Refactoring
    no selling
    needed
    easy to sell
    can often sell
    very hard to sell

    View Slide

  28. Selling refactoring is hard
    ⏲ ⛔

    View Slide

  29. Business priority
    Cost / risks
    Refactoring

    View Slide

  30. Too much pressure
    ⏳ ⚒

    View Slide

  31. Refactors are scary

    View Slide

  32. What techniques we have?
    PDD - Pray Driven Development
    Fowler’s refactoring book
    Characterization testing
    A/B testing, experiments

    View Slide

  33. Refactors as surgeries

    View Slide

  34. Refactors as surgeries
    Requires careful planning
    Follow a clear process
    Multiple observations
    Flexible tools
    Things can get bloody

    View Slide

  35. 1. Plan
    2. Cut
    3. Record
    4. Validate
    5. Refactor
    6. Verify
    7. Compare
    8. Fallback
    9. Delete
    Clear process

    View Slide

  36. View Slide

  37. View Slide

  38. View Slide

  39. Cut

    View Slide

  40. Record

    View Slide

  41. Validate ✅

    View Slide

  42. Refactor

    View Slide

  43. Verify

    View Slide

  44. Compare ⚖

    View Slide

  45. Fallback

    View Slide

  46. Delete ✂

    View Slide

  47. We dit it

    View Slide

  48. We dit it
    Time to celebrate hard

    View Slide