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

ReactiveConf: Lessons Migrating Complex Software

ReactiveConf: Lessons Migrating Complex Software

Jack Franklin

October 26, 2017

More Decks by Jack Franklin

Other Decks in Technology


  1. None
  2. !

  3. Migrating complex so!ware @Jack_Franklin

  4. None
  5. Thank you Kristina!

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

    to avoid elevators.
  7. None
  8. None
  9. None
  10. None
  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 —

  17. Tech

  18. None
  19. Big bang vs incremental

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

  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  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>
  37. None
  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>
  40. None
  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="..." />

  43. None
  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.
  51. None
  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
  55. None
  56. None
  57. None
  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

  61. None
  62. None
  63. None
  64. Mix larger, multi-week work with short, 1-2 day work, to

    keep momentum.
  65. None
  66. Break down large work into smaller cards and pull requests

  67. Feature branches

  68. None
  69. None
  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

  79. None
  80. None
  81. None
  82. None
  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"
  91. None
  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

  95. None
  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!

  114. None
  115. @Jack_Franklin jack@thread.com Pictures from pixabay.com

  116. None