$30 off During Our Annual Pro Sale. View Details »

ReactiveConf: Lessons Migrating Complex Software

ReactiveConf: Lessons Migrating Complex Software

Jack Franklin

October 26, 2017
Tweet

More Decks by Jack Franklin

Other Decks in Technology

Transcript

  1. View Slide

  2. !

    View Slide

  3. Migrating complex so!ware
    @Jack_Franklin

    View Slide

  4. View Slide

  5. Thank you
    Kristina!

    View Slide

  6. Thank you
    Kristina!
    From now on I'll
    be taking steps
    to avoid
    elevators.

    View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. The Store

    View Slide

  12. Started 2 years ago, built on Angular 1
    Tickets being sold constantly
    Used by our flagship clients

    View Slide

  13. The store works well.
    But changing it is very tricky.

    View Slide

  14. Legacy codebase
    An old version of Angular 1
    Feature bloat
    Original developers have gone

    View Slide

  15. We lack confidence in our system.

    View Slide

  16. The Four T's
    — Tech
    — Tests
    — Team
    — Talking

    View Slide

  17. Tech

    View Slide

  18. View Slide

  19. Big bang vs incremental

    View Slide

  20. View Slide

  21. View Slide

  22. View Slide

  23. View Slide

  24. Bit by bit !
    Release early and often, one bit by a time
    Learn as we migrate and get better at it
    Don't break any existing functionality

    View Slide

  25. https://www.martinfowler.com/bliki/
    StranglerApplication.html

    View Slide

  26. We shipped migrated code the
    day a!er starting this
    migration.

    View Slide

  27. The Theory
    Components (or directives in Angular)

    View Slide

  28. View Slide

  29. View Slide

  30. View Slide

  31. View Slide

  32. View Slide

  33. View Slide

  34. Migrating a component

    View Slide

  35. Write the React component
    import React, { Component } from 'react'
    class ListingsButton extends Component {
    // code left out to save space :)
    render() {
    return (
    Buy now!
    )
    }
    }

    View Slide

  36. But how do we embed this within Angular?
    Angular directives are used as if they were custom HTML elements:

    Rihanna at The O2
    Buy now

    View Slide

  37. View Slide

  38. With ngReact

    Rihanna at The O2


    View Slide

  39. We can continue this strategy, migrating the other
    components to React:




    View Slide

  40. View Slide

  41. And now we can migrate this into one big React
    component!
    import React, { Component } from 'react'
    import ListingsTitle from './listings-title'
    import ListingsButton from './listings-button'
    class ListingsItem extends Component {
    render() {
    return (




    )
    }
    }

    View Slide

  42. And update our template

    View Slide

  43. View Slide

  44. And we now rinse and repeat
    as we replace Angular with
    React.

    View Slide

  45. Tests

    View Slide

  46. We cannot break the store

    View Slide

  47. Unit tests
    Migrated from Angular to React + added to as
    appropriate.

    View Slide

  48. https://www.sitepoint.com/test-react-components-jest/

    View Slide

  49. Unit tests are coupled to the
    implementation code.

    View Slide

  50. Acceptance tests
    Automated tests that are entirely
    decoupled to the application code.

    View Slide

  51. View Slide

  52. Slow to run - so we select key
    user flows to cover.

    View Slide

  53. Team

    View Slide

  54. Keeping people happy and productive
    We knew this migration was going to be at least 6
    months, more likely closer to a year. 1
    1 It was a year

    View Slide

  55. View Slide

  56. View Slide

  57. View Slide

  58. Momentum & Prioritisation

    View Slide

  59. One of the goals of this migration is to make it easier to
    fix bugs with confidence.

    View Slide

  60. Pick work based on bugs and
    churn rate, not code quality

    View Slide

  61. View Slide

  62. View Slide

  63. View Slide

  64. Mix larger, multi-week work
    with short, 1-2 day work, to
    keep momentum.

    View Slide

  65. View Slide

  66. Break down large work into smaller cards and pull
    requests

    View Slide

  67. Feature branches

    View Slide

  68. View Slide

  69. View Slide

  70. Release early, release o!en
    Encourages small pull requests and units of work

    View Slide

  71. Release early, release o!en
    Keeps momentum up in the team and keeps risk to a
    minimum

    View Slide

  72. Release early, release o!en
    ! Easier to react 2 to a bug if release causes it
    2 pun very much intended

    View Slide

  73. The scout's rule
    Always leave things better than when you found them.

    View Slide

  74. A migrated codebase is not a
    perfect code base

    View Slide

  75. The next time you touch some code, you'll know more
    about it than before.
    So why make it perfect now?

    View Slide

  76. The lo!ery factor
    Thanks to https://twitter.com/aaronjrandall for the term

    View Slide

  77. knowledge-base.md

    View Slide

  78. Metrics, metrics, metrics

    View Slide

  79. View Slide

  80. View Slide

  81. View Slide

  82. View Slide

  83. Tooling

    View Slide

  84. Migrations are a good excuse
    to upgrade your tools.

    View Slide

  85. By providing a mix of migration
    tasks (big, small, visual,
    "under the hood", tooling),
    we're able to keep work fun
    and interesting

    View Slide

  86. Talking

    View Slide

  87. The most important people to
    convince are not in your tech
    team.

    View Slide

  88. And they don't care about
    frameworks

    View Slide

  89. "React's lifecycle methods and
    small API is easier for developers
    to learn"

    View Slide

  90. "React's state model is less
    magical; its unidirectional data flow
    really simplifies code and makes it
    easier to reason about"

    View Slide

  91. View Slide

  92. "Right now when you ask us for a
    new feature, or bug fix, it's hard
    and takes a long time to fix and
    have confidence that we've not
    inadvertently broken anything else"

    View Slide

  93. "We will improve our mobile load
    time + performance so users on
    mobiles should see fewer issues
    and have a nicer experience"

    View Slide

  94. Fix bugs that cause pain for
    other departments

    View Slide

  95. View Slide

  96. Keep people in the loop

    View Slide

  97. Deal with !

    View Slide

  98. http://gunshowcomic.com/648

    View Slide

  99. We put a lot of work into making sure things don't go
    wrong on production.
    But unfortunately they will, at some point.

    View Slide

  100. There are two types of
    developer 3
    3 shamelessly stolen from Twitter! https://twitter.com/beerops/status/866808660030345218

    View Slide

  101. Those who have broken production
    Those who are about to break
    production

    View Slide

  102. Apologies to the 3 people who
    bought tickets for a concert on
    the wrong day in Tokyo
    because of me !
    We did fix it though and sort these people out! :)

    View Slide

  103. 1. What? went wrong
    2. Why? did we not catch it
    3. How? did we fix it
    4. How? will we prevent it happening again

    View Slide

  104. It's a two way street

    View Slide

  105. Takeaways

    View Slide

  106. 1. Don't migrate for the sake of
    it

    View Slide

  107. 2. Plan, plan and plan again

    View Slide

  108. 3. Cross business
    communication is so
    important.

    View Slide

  109. 4. Prioritise based on pain
    points in your current
    application

    View Slide

  110. 5. Mix up tasks based on
    difficulty + type to keep it
    interesting

    View Slide

  111. 6. Have metrics to track
    progress internally and
    externally

    View Slide

  112. 7. Don't expect to migrate
    perfectly the first time

    View Slide

  113. ! Thank you!

    View Slide

  114. View Slide

  115. @Jack_Franklin
    [email protected]
    Pictures from pixabay.com

    View Slide

  116. View Slide