Impact Analysis в дизайн-системе: как мы сделали CI осмысленнее, а review понятнее

В сфере искусственного интеллекта произошло заметное событие. Daniil_Gilin 1 час назад Impact Analysis в дизайн-системе: как мы сделали CI осмысленнее, а review понятнее Средний 12 мин 3. 1K Блог компании БКС Финтех Разработка мобильных приложений * Тестирование IT-систем * Системное администрирование * Дизайн мобильных приложений * Кейс Меня зовут Даниил, я Android-разработчик в «БКС Мир инвестиций». В первой статье мой коллега рассказывал, как мы использовали Kotlin IR Compiler Plugin, чтобы автоматически добавлять testTag и semantics в Compose-компоненты: Kotlin IR Compiler Plugin в дизайн-системе: автотесты с Compose без ручной разметки.

Эта статья — следующий шаг: как мы начали использовать информацию о структуре дизайн-системы, чтобы понимать область влияния изменения. Если коротко, то кейс выглядит вот так:Проблема: маленькая правка в базовом компоненте может повлиять на несколько составных компонентов, состояний, превью и тестовых сценариев. По диффу не всегда понятно, где заканчивается реальный риск.

Технические детали

Решение: мы строим карту влияния — структурированное описание компонентов и связей «кто кого использует», на уровне самой дизайн-системы. Compiler plugin сохраняет manifest этих связей, а impact analysis превращает изменение в описанную зону риска. Результат: CI в первую очередь запускает проверки, привязанные к затронутым компонентам и к цепочке их использования от источника изменения, а отчёт в merge request показывает автору, ревьюеру, тестировщику и дизайнеру, что задели напрямую, что может быть затронуто по цепочке, какие проверки уже есть и где покрытие стоит усилить.

Для нас это оказалось важнее, чем просто “запускать меньше тестов”. Impact analysis стал общим языком между CI, разработчиком, ревьюером, тестировщиком и дизайнером. CI получает список необходимых проверок, а люди получают контекст риска: какие компоненты и сценарии стоит проверить дополнительно, даже если они не менялись напрямую.

Дальше расскажу, как мы переложили impact analysis на язык компонентной библиотеки: построили карту зависимостей, связали её с превью и тестами и превратили результат в понятный отчёт для merge request. Почему полный прогон перестал быть хорошим ответомПока библиотека компонентов небольшая, полный прогон тестов после каждого изменения выглядит естественно. Он простой, понятный и безопасный.

Отраслевые последствия

Но дизайн-система постепенно растёт:компонентов становится больше;появляются разные уровни: core, base, составные компоненты;один компонент начинает использовать другие;у компонентов появляются состояния, варианты отображения, превью;растёт число unit, screenshot, автотестов;разные продуктовые команды зависят от одной общей библиотеки. В такой системе маленькая правка не всегда остаётся маленькой. Например, разработчик меняет состояние базовой кнопки.

По размеру изменение может быть небольшим. Но эта кнопка используется в других компонентах: формах, селектах, панелях действий, экранах с несколькими состояниями. Значит, риск находится не только в одном файле и не только в одном компоненте.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.