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

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

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. 1 млн.
   пользователей
   используют ManyChat
   для маркетинга, продаж
   и поддержки
   500 млн.
   подписчиков
   взаимодействуют
   с ботами наших
   клиентов
   8 млрд.
   сообщений
   ежемесячно отправляют
   с помощью ManyChat
   190+
   Стран
   в которых используют
   ManyChat
   100+
   человек
   команда ManyChat
   65
   человек
   команда разработки
   2
   офиса
   в Москве
   и Сан-Франциско
   

   View Slide

5. View Slide

6. View Slide

7. Архитектурные особенности ManyChat
   ● Авторизация основана на Facebook OAuth2
   ● Без подключенной страницы Facebook ничего не работает
   ● Ядро базы завязано на IDs сущностей Facebook
   Ехал Facebook через Facebook, видит Facebook в Facebook Facebook, сунул
   Facebook Facebook в Facebook, Facebook Facebook Facebook Facebook
   

   View Slide

8. Что в итоге случилось
   ● Апрель 2019 - а давайте попробуем SMS и Email
   ● Июнь 2019 - а давайте это будет главной фишкой для конфы
   ● Сентябрь 2019 - а давайте всё это будет работать без Facebook
   ● Декабрь 2019 - а давайте полностью изолируемся
   вы находитесь здесь
   ● ------ 2020 - а давайте легко будем добавлять любые каналы
   ● ------ 2020 - любая фантазия на ваш вкус
   ● ------ 2020 - а можно я уже посплю, пожалуйста...
   

   View Slide

9. View Slide

10. View Slide

11. Внезапно. Legacy
    

    View Slide

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

    View Slide

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

    View Slide

14. План
    рефакторинга
    

    View Slide

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

    View Slide

16. API тесты
    

    View Slide

17. API тесты
    1. Покрываем тестами все public методы компонента
    2. State и context не нужно создавать, если их нет
    3. Mocks создаются только на внешние API, нужно проверить
    консистентность вызовов и состояния в хранилищах
    4. Сбор метрик и аналитики также покрываются тестами
    

    View Slide

18. View Slide

19. View Slide

20. Новая
    версия
    компонента
    

    View Slide

21. Новая версия компонента
    1. Фиксируем facade получившегося компонента через interface
    2. Создаем его полную копию
    3. Рефакторим новую версию, опираясь на ранее написанные тесты
    4. Если позволяют ресурсы, создаем тесты на полную эквивалентность
    возвращаемых данных
    Вы закончили, если тесты эквивалентно проходят и на старой и на новой
    версии компонента
    

    View Slide

22. Тоже лает
    Тоже бегает
    Тоже ест корм
    Но трогать уже не страшно
    V1 V2
    

    View Slide

23. Идем
    на
    PRODUCTION
    

    View Slide

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

    View Slide

25. Как же всего этого избежать?
    1. ManyChat EarlyAccess Community
    2. ManyChat Community
    3. Target accounts
    4. Пошаговая медленная раскатка по схеме шардинга
    

    View Slide

26. View Slide

27. Катимся очень нежно
    1. Фиксируем версию компонента в метриках
    2. Балансируем работу 2-х компонентов
    3. Выдаем точечно
    4. Регулярно общаемся с саппортом
    

    View Slide

28. На выходе
    

    View Slide

29. Что получилось
    1. Привели кодовую базу в порядок
    2. Написали верхнеуровневые тесты на консистентность
    3. Изолировали и реорганизовали ряд компонентов
    4. Раскатали это на пользователей без серьезных проблем
    5. Схема раскатки выросла в общий паттерн sensitive deploy
    

    View Slide

30. Anton Zhukov
    

    View Slide