ReactiveConf: Lessons Migrating Complex Software

2. !
3. Migrating complex so!ware @Jack_Franklin
5. Thank you Kristina!
6. Thank you Kristina! From now on I'll be taking steps to avoid elevators.
11. The Store
12. Started 2 years ago, built on Angular 1 Tickets being sold constantly Used by our flagship clients
13. The store works well. But changing it is very tricky.
14. Legacy codebase An old version of Angular 1 Feature bloat Original developers have gone
15. We lack confidence in our system.
16. The Four T's — Tech — Tests — Team — Talking
17. Tech
19. Big bang vs incremental
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
25. https://www.martinfowler.com/bliki/ StranglerApplication.html
26. We shipped migrated code the day a!er starting this migration.
27. The Theory Components (or directives in Angular)
34. Migrating a component
35. 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> ) } }
36. 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. With ngReact <li> <h2>Rihanna at The O2</h2> <react-component name="ListingsButton" props="..." /> </li>
39. We can continue this strategy, migrating the other components to React: <li> <react-component name="ListingsTitle" props="..." /> <react-component name="ListingsButton" props="..." /> </li>
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 ( <li> <ListingsTitle ... /> <ListingsButton ... /> </li> ) } }
42. And update our template <react-component name="ListingsItem" props="..." />
44. And we now rinse and repeat as we replace Angular with React.
45. Tests
46. We cannot break the store
47. Unit tests Migrated from Angular to React + added to as appropriate.
48. https://www.sitepoint.com/test-react-components-jest/
49. Unit tests are coupled to the implementation code.
50. Acceptance tests Automated tests that are entirely decoupled to the application code.
52. Slow to run - so we select key user flows to cover.
53. Team
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
58. Momentum & Prioritisation
59. One of the goals of this migration is to make it easier to fix bugs with confidence.
60. Pick work based on bugs and churn rate, not code quality
64. Mix larger, multi-week work with short, 1-2 day work, to keep momentum.
66. Break down large work into smaller cards and pull requests
67. Feature branches
70. Release early, release o!en Encourages small pull requests and units of work
71. Release early, release o!en Keeps momentum up in the team and keeps risk to a minimum
72. Release early, release o!en ! Easier to react 2 to a bug if release causes it 2 pun very much intended
73. The scout's rule Always leave things better than when you found them.
74. A migrated codebase is not a perfect code base
75. The next time you touch some code, you'll know more about it than before. So why make it perfect now?
76. The lo!ery factor Thanks to https://twitter.com/aaronjrandall for the term
77. knowledge-base.md
78. Metrics, metrics, metrics
83. Tooling
84. Migrations are a good excuse to upgrade your tools.
85. By providing a mix of migration tasks (big, small, visual, "under the hood", tooling), we're able to keep work fun and interesting
86. Talking
87. The most important people to convince are not in your tech team.
88. And they don't care about frameworks
89. "React's lifecycle methods and small API is easier for developers to learn"
90. "React's state model is less magical; its unidirectional data flow really simplifies code and makes it easier to reason about"
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"
93. "We will improve our mobile load time + performance so users on mobiles should see fewer issues and have a nicer experience"
94. Fix bugs that cause pain for other departments
96. Keep people in the loop
97. Deal with !
98. http://gunshowcomic.com/648
99. We put a lot of work into making sure things don't go wrong on production. But unfortunately they will, at some point.
100. There are two types of developer 3 3 shamelessly stolen from Twitter! https://twitter.com/beerops/status/866808660030345218
101. Those who have broken production Those who are about to break production
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! :)
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
104. It's a two way street
105. Takeaways
106. 1. Don't migrate for the sake of it
107. 2. Plan, plan and plan again
108. 3. Cross business communication is so important.
109. 4. Prioritise based on pain points in your current application
110. 5. Mix up tasks based on difficulty + type to keep it interesting
111. 6. Have metrics to track progress internally and externally
112. 7. Don't expect to migrate perfectly the first time
113. ! Thank you!
115. @Jack_Franklin jack@thread.com Pictures from pixabay.com