У Meta больше 10 тысяч внутренних продуктов и страниц, а поддержкой платформы для них занимается команда примерно из 10 инженеров. На этом фоне история про внутренние инструменты Meta перестает быть локальной кухней большой корпорации: это уже практический разбор того, как не утонуть в собственном монорепозитории, когда половина веб-кода компании относится к внутренним сервисам, а не к пользовательскому продукту.
На конференции QCon San Francisco фронтенд-инженер Meta Синди Чжан рассказала, как внутри компании выросла система XDS, единый UI-слой для разработки служебных интерфейсов, сообщает InfoQ. По ее словам, сейчас более 95% продуктовых команд используют компоненты XDS для сборки своих инструментов, а каждое полугодие код для внутреннего tooling пишут тысячи инженеров из более чем 100 организаций. Для архитекторов, тимлидов и платформенных команд здесь важны не красивые слова про дизайн-систему, а конкретные приемы: как запускать grassroots-инициативу, как проводить массовые рефакторинги без пожара и как превратить библиотеку компонентов в полноценную платформу.
Отправная точка у Meta была узнаваемая для любой крупной компании. Шесть лет назад внутренние сервисы строились поверх веб-инфраструктуры и компонентов, рассчитанных в первую очередь на внешние продукты Facebook. Для служебных интерфейсов этого оказалось мало: нужны более плотные таблицы, сложный поиск, типовые layout-паттерны, формы и навигация, которые редко бывают критичны для социальной сети, но ежедневно нужны операционным, аналитическим и инженерным командам. Параллельно разные команды снова и снова собирали похожие компоненты у себя, потому что общего решения либо не было, либо оно не отвечало их задачам.
Собственно, из этого и вырос XDS, сокращение от cross-design system. Название здесь не ради брендинга, а ради организационной логики: команда с самого начала хотела сделать не набор виджетов для одного подразделения, а унифицированную систему для всех внутренних инструментов Meta. Причем ставка была сделана не на долгую фазу проектирования, а на быстрый выход в прод. Чжан отдельно вспоминает предыдущую попытку создать внутреннюю дизайн-систему, которая провалилась, потому что застряла на стадии идеального дизайна и процессов. Новый подход был противоположным: два инженера и четыре дизайнера в part-time-режиме за полгода собрали стартовую версию со 100-plus компонентами. Вывод грубоватый, но рабочий: если платформа слишком долго рисует саму себя, она обычно не взлетает.
Интересно, что adoption-стратегия у Meta строилась не вокруг абстрактной консистентности, а вокруг боли, которую команды готовы отдать на аутсорс платформе. Одним из первых кейсов стал сложный компонент фильтрации PowerSearch. Его перевели на XDS, одновременно подтянув доступность и удобство использования. Поскольку PowerSearch уже стоял в нескольких сотнях инструментов, миграция дала XDS мгновенное присутствие в реальном продакшене без уговоров в духе «пожалуйста, перепишите все на новый стек». Второй ход был не менее прагматичным: команда добавила вещи, которых раньше просто не было, например контекстную систему форм для управления состоянием, а также поддержку темизации и dark mode. Когда платформа не только унифицирует старое, но и приносит новые возможности, сопротивление заметно падает.
Дальше начинается самый интересный для инженерных руководителей слой: как масштабировать систему, если у тебя не десяток потребителей, а тысячи контрибьюторов и огромный монорепозиторий. По словам Чжан, внутренние инструменты Meta дают около 50% всего объема веб-кодовой базы компании. В такой среде любое лобовое breaking change быстро превращается в корпоративный спорт с элементами выгорания. Поэтому команда XDS опирается на безопасные рефакторинги через JS AST, автоматические кодемоды и AI-codemods, которые помогают массово обновлять использование компонентов. Это не история про «ИИ сам переписал фронтенд», а про то, что генеративные инструменты начинают работать как ускоритель для механических миграций, если архитектура и типы изменений заранее понятны.
Не менее показателен и подход к совместимости. Meta не пытается делать вид, что большие платформенные изменения можно провести незаметно для всех. Вместо этого в докладе отдельно подчеркивается роль feature flags как страховки от поломок при внедрении новых версий компонентов и паттернов. Для компаний с монорепозиторием это звучит почти банально, но именно такие банальные вещи чаще всего и игнорируют на старте внутренних платформ. Пока все маленькое, хочется «просто обновить API». Когда потребителей тысячи, любое «просто» начинает стоить недель координации, ручной проверки и политических переговоров между командами.
Еще один важный сдвиг в истории XDS: библиотека компонентов со временем перестала быть только библиотекой компонентов. Сейчас команда Чжан поддерживает не только UI-слой, но и более широкую платформу для внутренних продуктов: routing-инфраструктуру, управление инструментами, observability и backend-системы для общих сценариев. Это, пожалуй, главный тезис для российских продуктовых и платформенных команд. На определенном масштабе дизайн-система почти неизбежно выходит за пределы кнопок, таблиц и токенов. Если бизнес хочет быстро собирать внутренние сервисы, нужна не просто единая визуальная оболочка, а набор сквозных стандартов и сервисов, которые сокращают цену запуска нового инструмента.
Для русскоязычной IT-аудитории здесь нет повода копировать Meta буквально: не у всех есть 10 тысяч внутренних сервисов, монорепозиторий такого размера и культура, где любой инженер может почти без ограждений поднять новый tool. Но сама логика хорошо переносится. Внутренние инструменты Meta показывают, что платформа начинает работать, когда решает конкретные повторяющиеся проблемы команд, быстро приносит заметную пользу и умеет переживать массовые изменения без ручного героизма. Открытый вопрос в другом: сколько компаний готовы признать, что их «библиотека компонентов для админки» уже давно просится в статус полноценной инженерной платформы, а не очередного side project между квартальными целями.