Комментарии 4
С увеличением количества обслуживаемых продуктов наша дизайн-система начала разваливаться. Вырос порог входа для дизайнеров и работать с ней стало труднее. В статье расскажу как мы перешли на модульную архитектуру и не растеряли консистентность.
Oladislav, представтесь пожалуйста.
Примеров нет. Рассказывают вроде про дизайн, а дизайн иллюстраций небрежный.
Найденное решение — это комбинация из первой и последней схемы стартовой иллюстрации в статье. Надо же — велосипедостроители! Такая схема использовалась со времен эпохи UNIX. Всё очень просто и, можно сказать, стандартно. Есть базовая библиотека на всю инфраструктуру (систему), плюс каждый проект (продукт) имеет свою специфическую библиотеку.
Автор, хорош, проблемы раскрыл. А найденное решение спорное. Предполагаю что в разработке все хорошо, а в поддержке на протяжении 2 лет будет не очень. Ведь со временем продукты и их собственные библиотеки будут все больше и больше расходиться. Синхронизировать и прийти к общему результату, или особенно провести полный редизайн всей системы — будет невероятной болью.
Я намучался и перешел к следующему подходу:
Библиотека слишком большая. Работая над фичей, дизайнер абстрагируется от перегруженной и сложной библиотеки. Он собирает и детачит компоненты прямо в рабочем файле, надеясь, что однажды они просто перетекут в библиотеку и станут "легальными". Чтож, удачи.
То есть рыцари круглого стола собираются и синхронизируют главную библиотеку продуктов на регулярной основе, раз в 1-2 недели.
А иллюстрации и объяснение отличное (смысл понятен мгновенно, и это самое важное)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура дизайн-системы для нескольких продуктов