Front Trends: Migrating complex software

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

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