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

«Масштабируемая архитектура фронтенда» — Роман Дворнов, Avito

«Масштабируемая архитектура фронтенда» — Роман Дворнов, Avito

AvitoTech

April 23, 2018
Tweet

More Decks by AvitoTech

Other Decks in Programming

Transcript

  1. Работаю в Avito Open source:
 basis.js, CSSO, 
 component-inspector, 


    csstree, rempl и другие github.com/lahmatiy twitter.com/rdvornov [email protected]
  2. Когда все сложно 8 Feature 1 Feature 2 Feature N

    ... Project 1 Project 2 ... Project N Team Team Team
  3. Когда все сложно 8 Feature 1 Feature 2 Feature N

    ... Project 1 Project 2 ... Project N Team Team Team
  4. В чем разница • Проект-команда • Плохая предсказуемость доставки фичи,

    сложно приоритезировать, разное понимание • Фича-команда • Много разных интеграций, но хорошая предсказуемость и проработка фич 10
  5. В чем разница • Проект-команда • Плохая предсказуемость доставки фичи,

    сложно приоритезировать, разное понимание • Фича-команда • Много разных интеграций, но хорошая предсказуемость и проработка фич 10 Было Сейчас
  6. Проблемы больших продуктов • Больше «проектов» – больше точек интеграции

    • Увеличивается число команд с одной кодовой базой • Постоянно усложняется (новые фичи) • Растет кодовая база и техдолг (легаси) • ... 12
  7. Типовые задачи • Лейаут страницы • Управление слоями • Загрузка

    и управление зависимостями • Источники данных (модели, нотификация) • Персистентное хранение данных • Транспорт • Роутинг • и т.д. 16
  8. Layout Slot 1 Slot 2 Slot N ... Core Block

    1 Block 2 Block N ... Plugin 1 Plugin 2 Plugin N
  9. Layout Slot 1 Slot 2 Slot N ... Core Block

    1 Block 2 Block N ... Plugin 1 Plugin 2 Plugin N Common Public API
  10. Layout Slot 1 Slot 2 Slot N ... Core Block

    1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... ... Plugin 1 Plugin 2 Plugin N Common Public API
  11. Layout Slot 1 Slot 2 Slot N ... Core Block

    1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... Browser API ... Plugin 1 Plugin 2 Plugin N Common Public API
  12. Layout Slot 1 Slot 2 Slot N ... Page Ecosystem

    Core Block 1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... Browser API ... Plugin 1 Plugin 2 Plugin N Common Public API
  13. Что может быть • Запрос к серверу • Данные из

    кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23
  14. Что может быть • Запрос к серверу • Данные из

    кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23 Progressive enhancement
  15. Реализация экосистемы может ... • Меняться (подходы и технологии) •

    Различаться от проекта к проекту • Совершенствоваться со временем • ... • Блокам/компонентам все равно 24
  16. Плюшки • Стенд для разработки блока • Моки без костылей

    • Реализации под «среду» • браузер • серверный рендеринг • тесты 25
  17. Зачем? • Переиспользование блоков без адаптации к API • Используем

    подходящую реализацию ядра, в зависимости от среды • Проще новые интеграции (меньше учить) 28
  18. «Нет» монолитам! • Подключение (с динамической подгрузкой) дополнительной функциональности в

    ядро по принципу плагинов • Интерфейсы декомпозируются на логические блоки, с динамической подгрузкой (включая зависимости) и обновлением 30
  19. Подход подразумевает • Функциональность (API) экосистемы расширяется (догружается) по мере

    потребностей блоков • Разные версии одних и тех же зависимостей в рамках одного окружения (страницы) • Блоки взаимодействуют только с публичным API • Креш блока не тянет за собой все остальное 31
  20. Точки отказа • Ядро – единственная критическая часть, ничего не

    будет работать • Плагин ядра – не будут работать плагины и блоки, которые от него зависят • Блок – проблемы блока никого не касаются 32
  21. Порядок и комфорт • Владение кодом • Независимость команд •

    Контроль зависимостей и версий • Инкрементальные рефакторинг и миграция 36
  22. Action plan • Проблема, баг или вопрос? • Определяется релевантный

    компонент, 
 с которым это связано и его владелец • Направляется запрос владельцу • Владелец решает вопрос сам или переадресует другим, но контролирует его разрешение 43
  23. Независимость команд • Модульность: блоки (функциональность) изолируются в пакеты •

    Могут использовать собственную версию зависимости, апгрейдится в удобное время • Поддержка более мягких интеграций • Автоматизация тестирования 46
  24. Типы интеграции • Жесткая интеграция – изменения кода компонента (требуется

    публикация пакета, пересборка и релиз зависимых модулей и проектов) • Конфигурационная интеграция – изменение конфигурации экземпляра компонента (требуется пересборка и релиз модуля и проекта) • Мета интеграция – конфигурация блока описывается и хранится вне кода (не требует пересборки и релиза) 47
  25. Инкрементальный рефакторинг • Возможность не делать все сразу • Рефакторинг

    не больше недели → релиз • Толерантность к легаси – старое должно продолжать работать без приложения усилий (консервация до лучших времен) 56
  26. Управление разработкой • Владение кодом • Независимость команд • Управление

    зависимостями и версиями • Инкрементальный рефакторинг 59
  27. Дизайн система • UI Kit (для дизайнеров) • UI компоненты

    (для разработчиков) • Каталог UI компонент • Общие паттерны и решения • ... 64
  28. Инфраструктура • Сборка проектов • Управление зависимостями, публикациями и версиями

    • Организация тестирования (настройка, инструменты, хелперы etc) • Репортинг (ошибки, performance, etc), мониторинг, Health Check • База знаний • Скрипты по сбору данных (анализ кода, тегирование, etc) • ... 70
  29. По моему скромному опыту: настроить проект с нуля, имея опыт,

    
 занимает несколько часов, не считая поддержки 72
  30. Инфраструктура – не всегда готовое • Unit-тестирование скриншотами: преодолеваем звуковой

    барьер – Роман Дворнов
 видео, расшифровка • Скриншоты как сервис – Сергей Мелюков
 видео 73
  31. не верьте мне на слово 79 Не все еще проверено

    в реальных условиях Ожидайте update через полгода