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

Front Trends: Migrating complex software

Front Trends: Migrating complex software

A talk about migrating complex software, based on my experience of Angular => React at Songkick.

Jack Franklin

May 25, 2017
Tweet

More Decks by Jack Franklin

Other Decks in Technology

Transcript

  1. !
    From Angular to React
    @Jack_Franklin

    View Slide

  2. Migrating complex so!ware

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. The Store

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  12. We can't iterate quickly, respond to bug reports, or build
    new features in a timely manner.
    We lack confidence in our system.

    View Slide

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

    View Slide

  14. Tech

    View Slide

  15. View Slide

  16. Big bang vs incremental

    View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

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

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

    View Slide

  23. http://2017.theleaddeveloper.com/ | @saleandro

    View Slide

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

    View Slide

  25. The Theory
    Components (or directives in Angular)

    View Slide

  26. View Slide

  27. View Slide

  28. View Slide

  29. View Slide

  30. The plan

    View Slide

  31. View Slide

  32. View Slide

  33. Migrating a component

    View Slide

  34. 1. Find all dependencies that a
    directive uses

    View Slide

  35. 2. Migrate all of those one by
    one to React

    View Slide

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

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

  38. View Slide

  39. With ngReact

    Rihanna at The O2


    View Slide

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




    View Slide

  41. View Slide

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

  43. And update our template

    View Slide

  44. View Slide

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

    View Slide

  46. Tests

    View Slide

  47. We cannot break the store

    View Slide

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

    View Slide

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

    View Slide

  50. Unit tests are coupled to the
    implementation code.

    View Slide

  51. Acceptance tests

    View Slide

  52. View Slide

  53. Automated tests that are
    entirely decoupled to the
    application code.

    View Slide

  54. Because they are slow to run,
    we keep acceptance tests to
    our core user journeys

    View Slide

  55. We also run our acceptance
    tests in IE11 to catch any IE
    bugs.
    Soon we hope to run them across all browsers we support, both desktop & mobile

    View Slide

  56. Team

    View Slide

  57. 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's been 9 months so far...

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

    View Slide

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

    View Slide

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

  87. Talking

    View Slide

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

    View Slide

  89. And they don't care about
    frameworks

    View Slide

  90. "Well, Angular 1 is reaching end
    of life and React offers a much
    be!er component model that
    fits our ideas of how to build
    so"ware"

    View Slide

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

    View Slide

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

    View Slide

  93. View Slide

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

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

    View Slide

  96. Fix bugs that cause pain for
    other departments

    View Slide

  97. View Slide

  98. Keep people in the loop

    View Slide

  99. Deal with !

    View Slide

  100. http://gunshowcomic.com/648

    View Slide

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

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

    View Slide

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

    View Slide

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

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

  106. View Slide

  107. View Slide

  108. It's a two way street

    View Slide

  109. Takeaways

    View Slide

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

    View Slide

  111. 2. Plan, plan and plan again

    View Slide

  112. 3. Cross business
    communication is so
    important.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  117. Thank you !
    @Jack_Franklin
    ! Please come and say hello :)
    Pictures from pixabay.com

    View Slide