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

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

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

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

No content

No content

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

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

No content

No content

Внезапно. Legacy

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

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

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

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

API тесты

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

No content

No content

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

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

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

Идем на PRODUCTION

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

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

No content

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

На выходе

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

Anton Zhukov