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

«Безболезненная победа над legacy» — Антон Жуков, ManyChat

De18318c9ff86ea93435effe50a43c4b?s=47 Badoo Tech
February 15, 2020

«Безболезненная победа над legacy» — Антон Жуков, ManyChat

Очередная встреча сообщества PHP-разработчиков в офисе Badoo.

«То, что вы сейчас называете новым кодом, разработанным с умом и с учетом текущего качества кодовой базы, через неопределенный срок превратится в legacy. Это срок может быть несколько недель, просто потому что новая фича не прошла A/B-тест. Может быть — несколько лет, когда страшный процедурный код, закрывший ряд проблем в моменте, оброс такими же страшными комитами, разросся до огромного компонента, который невозможно читать, но как-то надо поддерживать.

В докладе я расскажу о том, как провести рефакторинг legacy-кода без влияния на работу приложения, протестировать функциональность и производительность, а также бесшовно переключиться на новую версию в production».

De18318c9ff86ea93435effe50a43c4b?s=128

Badoo Tech

February 15, 2020
Tweet

More Decks by Badoo Tech

Other Decks in Programming

Transcript

  1. Безболезненная победа над legacy Anton Zhukov

  2. Боль, через которую мы прошли, чтобы больше ее не испытывать

  3. Что такое ManyChat? Платформа для автоматизации маркетинга Помогаем бизнесам расти,

    выстраивая осмысленные отношения со своими пользователями
  4. 1 млн. пользователей используют ManyChat для маркетинга, продаж и поддержки

    500 млн. подписчиков взаимодействуют с ботами наших клиентов 8 млрд. сообщений ежемесячно отправляют с помощью ManyChat 190+ Стран в которых используют ManyChat 100+ человек команда ManyChat 65 человек команда разработки 2 офиса в Москве и Сан-Франциско
  5. None
  6. None
  7. Архитектурные особенности ManyChat • Авторизация основана на Facebook OAuth2 •

    Без подключенной страницы Facebook ничего не работает • Ядро базы завязано на IDs сущностей Facebook Ехал Facebook через Facebook, видит Facebook в Facebook Facebook, сунул Facebook Facebook в Facebook, Facebook Facebook Facebook Facebook
  8. Что в итоге случилось • Апрель 2019 - а давайте

    попробуем SMS и Email • Июнь 2019 - а давайте это будет главной фишкой для конфы • Сентябрь 2019 - а давайте всё это будет работать без Facebook • Декабрь 2019 - а давайте полностью изолируемся вы находитесь здесь • ------ 2020 - а давайте легко будем добавлять любые каналы • ------ 2020 - любая фантазия на ваш вкус • ------ 2020 - а можно я уже посплю, пожалуйста...
  9. None
  10. None
  11. Внезапно. Legacy

  12. Тревожные звоночки • Код, который больше нигде не используется •

    Унаследованный код, не устойчивый к изменениям • Грязный код, который дорого поддерживать • Ресурсоемкий код • Избыточно распределенный по проекту код
  13. Когда пора бить тревогу • Как только компонент начинает расти

    • Никогда Принцип • Нужно оптимизировать то, что создает регулярные проблемы • Не нужно тратить время на код, который меняется редко
  14. План рефакторинга

  15. План рефакторинга 1. Поиск жесткой связности кода компонента 2. Покрытие

    тестами этой связности 3. Снижение уровня связности 4. Замыкание вызовов на Facade или Manager 5. Фиксация метрик потоков, конверсии, производительности, etc Вы закончили, если в текущем состоянии компонент можно вынести в отдельный репозитарий и использовать как вендорную зависимость
  16. API тесты

  17. API тесты 1. Покрываем тестами все public методы компонента 2.

    State и context не нужно создавать, если их нет 3. Mocks создаются только на внешние API, нужно проверить консистентность вызовов и состояния в хранилищах 4. Сбор метрик и аналитики также покрываются тестами
  18. None
  19. None
  20. Новая версия компонента

  21. Новая версия компонента 1. Фиксируем facade получившегося компонента через interface

    2. Создаем его полную копию 3. Рефакторим новую версию, опираясь на ранее написанные тесты 4. Если позволяют ресурсы, создаем тесты на полную эквивалентность возвращаемых данных Вы закончили, если тесты эквивалентно проходят и на старой и на новой версии компонента
  22. Тоже лает Тоже бегает Тоже ест корм Но трогать уже

    не страшно V1 V2
  23. Идем на PRODUCTION

  24. Понемножку покатились... 1. DevOps перекрестился перед деплоем 2. Пользователям не

    нравится, что кнопка “Удалить бота” удаляет бота 3. Не получается заново привязать страницу в 1 клик 4. 1 аккаунт = 1 бот, иначе нарушение консистентности базы 5. “Дуров верни стену!” 6. etc А это всего лишь 1%...
  25. Как же всего этого избежать? 1. ManyChat EarlyAccess Community 2.

    ManyChat Community 3. Target accounts 4. Пошаговая медленная раскатка по схеме шардинга
  26. None
  27. Катимся очень нежно 1. Фиксируем версию компонента в метриках 2.

    Балансируем работу 2-х компонентов 3. Выдаем точечно 4. Регулярно общаемся с саппортом
  28. На выходе

  29. Что получилось 1. Привели кодовую базу в порядок 2. Написали

    верхнеуровневые тесты на консистентность 3. Изолировали и реорганизовали ряд компонентов 4. Раскатали это на пользователей без серьезных проблем 5. Схема раскатки выросла в общий паттерн sensitive deploy
  30. Anton Zhukov