Front Trends: Migrating complex software

Transcript

1. 1.

   ! From Angular to React @Jack_Franklin

2. 2.

   Migrating complex so!ware

3. 3.

   None
4. 4.

   None
5. 5.

   None
6. 6.

   None
7. 7.

   None
8. 8.

   The Store

9. 9.

   Started 2 years ago, built on Angular 1 Tickets being

   sold constantly Used by our flagship clients
10. 10.

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

11. 11.

    Legacy codebase An old version of Angular 1 Feature bloat

    Original developers have gone
12. 12.

    We can't iterate quickly, respond to bug reports, or build

    new features in a timely manner. We lack confidence in our system.
13. 13.

    The Four T's — Tech — Tests — Team —

    Talking
14. 14.

    Tech

15. 15.

    None
16. 16.

    Big bang vs incremental

17. 17.

    None
18. 18.

    None
19. 19.

    None
20. 20.

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

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

23. 23.

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

24. 24.

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

25. 25.

    The Theory Components (or directives in Angular)

26. 26.

    None
27. 27.

    None
28. 28.

    None
29. 29.

    None
30. 30.

    The plan

31. 31.

    None
32. 32.

    None
33. 33.

    Migrating a component

34. 34.

    1. Find all dependencies that a directive uses

35. 35.

    2. Migrate all of those one by one to React

36. 36.

    3. Write the React component import React, { Component }

    from 'react' class ListingsButton extends Component { // code left out to save space :) render() { return ( <a href="" className="">Buy now!</a> ) } }
37. 37.

    But how do we embed this within Angular? Angular directives

    are used as if they were custom HTML elements: <li> <h2>Rihanna at The O2</h2> <listings-button url="...">Buy now</listings-button> </li>
38. 38.

    None
39. 39.

    With ngReact <li> <h2>Rihanna at The O2</h2> <react-component name="ListingsButton" props="..."

    /> </li>
40. 40.

    We can continue this strategy, migrating the other components to

    React: <li> <react-component name="ListingsTitle" props="..." /> <react-component name="ListingsButton" props="..." /> </li>
41. 41.

    None
42. 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 ( <li> <ListingsTitle ... /> <ListingsButton ... /> </li> ) } }
43. 43.

    And update our template <react-component name="ListingsItem" props="..." />

44. 44.

    None
45. 45.

    And we now rinse and repeat as we replace Angular

    with React Forever.
46. 46.

    Tests

47. 47.

    We cannot break the store

48. 48.

    Unit tests Migrated from Angular to React + added to

    as appropriate.
49. 49.

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

50. 50.

    Unit tests are coupled to the implementation code.

51. 51.

    Acceptance tests

52. 52.

    None
53. 53.

    Automated tests that are entirely decoupled to the application code.

54. 54.

    Because they are slow to run, we keep acceptance tests

    to our core user journeys
55. 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
56. 56.

    Team

57. 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...
58. 58.

    Momentum & Prioritisation

59. 59.

    One of the goals of this migration is to make

    it easier to fix bugs with confidence.
60. 60.

    Pick work based on bugs and churn rate, not code

    quality
61. 61.

    None
62. 62.

    None
63. 63.

    None
64. 64.

    Mix larger, multi-week work with short, 1-2 day work, to

    keep momentum.
65. 65.

    None
66. 66.

    Break down large work into smaller cards and pull requests

67. 67.

    Feature branches

68. 68.

    None
69. 69.

    None
70. 70.

    Release early, release o!en Encourages small pull requests and units

    of work
71. 71.

    Release early, release o!en Keeps momentum up in the team

    and keeps risk to a minimum
72. 72.

    Release early, release o!en ! Easier to react 2 to

    a bug if release causes it 2 pun very much intended
73. 73.

    The scout's rule Always leave things better than when you

    found them.
74. 74.

    A migrated codebase is not a perfect code base

75. 75.

    The next time you touch some code, you'll know more

    about it than before. So why make it perfect now?
76. 76.

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

77. 77.

    None
78. 78.

    Metrics, metrics, metrics

79. 79.

    None
80. 80.

    None
81. 81.

    None
82. 82.

    None
83. 83.

    Tooling

84. 84.

    hashtag fatigue

85. 85.

    Migrations are a good excuse to upgrade your tools.

86. 86.

    By providing a mix of migration tasks (big, small, visual,

    "under the hood", tooling), we're able to keep work fun and interesting
87. 87.

    Talking

88. 88.

    The most important people to convince are not in your

    tech team.
89. 89.

    And they don't care about frameworks

90. 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"
91. 91.

    "React's lifecycle methods and small API is easier for developers

    to learn"
92. 92.

    "React's state model is less magical; its unidirectional data flow

    really simplifies code and makes it easier to reason about"
93. 93.

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

    "We will improve our mobile load time + performance so

    users on mobiles should see fewer issues and have a nicer experience"
96. 96.

    Fix bugs that cause pain for other departments

97. 97.

    None
98. 98.

    Keep people in the loop

99. 99.

    Deal with !

100. 100.

     http://gunshowcomic.com/648

101. 101.

     We put a lot of work into making sure things

     don't go wrong on production. But unfortunately they will, at some point.
102. 102.

     There are two types of developer 3 3 shamelessly stolen

     from Twitter! https://twitter.com/beerops/status/866808660030345218
103. 103.

     Those who have broken production Those who are about to

     break production
104. 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! :)
105. 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
106. 106.

     None
107. 107.

     None
108. 108.

     It's a two way street

109. 109.

     Takeaways

110. 110.

     1. Don't migrate for the sake of it

111. 111.

     2. Plan, plan and plan again

112. 112.

     3. Cross business communication is so important.

113. 113.

     4. Prioritise based on pain points in your current application

114. 114.

     5. Mix up tasks based on difficulty + type to

     keep it interesting
115. 115.

     6. Have metrics to track progress internally and externally

116. 116.

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

117. 117.

     Thank you ! @Jack_Franklin ! Please come and say hello

     :) Pictures from pixabay.com