То, что вы описываете - это Atomic Design подход, когда из простых элементов составляются более сложные. В статье важно другое – что в UI-ките компоненты остаются отвязаными от бизнес-логики (тупыми), независимо от их сложности.
Мне жаль, что создаётся такое впечатление. Потому что это интервью - полностью моя инициатива. Так как люди действительно задают вопросы о том, как работается с иностранцами/за границей.
Наш герой Артем тоже разделял вашу позицию, пока не оказался в Лондоне. Каждому, определенно, свое! Интересно было бы узнать и про ваш опыт тоже, спасибо что делитесь.
Как видите, многие аспекты работы дизайн-команды не до конца учитываются в приведенной вами стандартной оценке, поэтому для работы нашей команды был изобретен этот велосипед :) Возможно, он пригодится и другим командам с похожими проблемами.
Здравствуйте! Я использую общепринятый термин, который встречается в большинстве русскоязычных источников об Agile. Но действительно стоит дать такое пояснение, благодарю!
Так как оценка происходит на общем собрании — мы обсуждаем ее коллективно и приходим к общему знаменателю. В оценки времени к общему знаменателю мы приходили долго, больно и порой не приходили вообще. В оценке сложностей это все случается сильно быстрее и не так болезненно.
Дело не в инструментах, а в подходах и командной работе.
Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.
Они остаются в коде (и в дизайне) как элементы компонента, готового к изменениям при необходимости. Если вас беспокоит проблема неиспользуемого кода, то, насколько мне известно, Storybook позволяет снизить его количество засчет хранения компонентов отдельно от кода продукта. Но тут меня разработчики могут поправить
В заглушке предусмотрены разные кнопочки или их отсутствие, и может не быть цены.
Это гибкий шаблон для применения в разных ситуациях, предусматривающий много разных состояний и кейсов
Абсолютно согласна, от проекта и от того насколько атомарны компоненты. Атомарность это ещё одна большая и болезненная тема дизайна и разработки интерфейсов в принципе.
Мне лично слова "глупый" и "тупой" кажутся наиболее подходящими, потому что отражают отсутствие привязки к контексту. Всё-таки "простой" это немного о другом. Но тут как вам удобнее))
Спасибо за комментарий! Я думаю, вы правы. Большую роль играет атомарность компонентов и сложность в том, чтобы определить, когда делить на компоненты, а когда нет. Бывает и так (и, по моему опыту, это происходит чаще), что код трудно поддерживать потому, что нет возможности поменять несколько мест сразу.
Возможно в случае нескольких проектов на одной библиотеке, стоит смотреть в сторону дизайн-системы и организовывать компоненты на двух уровнях: простые тупые на уровне дизайн-системы и умные на уровне проекта. Как бы библиотека в библиотеке.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо, Женя, за такую развёрнутую и прикладную статью ❤️
Отличное пособие, отправляется в рекомендованную литературу для моих студентов)))
То, что вы описываете - это Atomic Design подход, когда из простых элементов составляются более сложные. В статье важно другое – что в UI-ките компоненты остаются отвязаными от бизнес-логики (тупыми), независимо от их сложности.
Мне жаль, что создаётся такое впечатление. Потому что это интервью - полностью моя инициатива. Так как люди действительно задают вопросы о том, как работается с иностранцами/за границей.
Наш герой Артем тоже разделял вашу позицию, пока не оказался в Лондоне. Каждому, определенно, свое! Интересно было бы узнать и про ваш опыт тоже, спасибо что делитесь.
Зависит от проектов, но в целом для всех есть возможность релокации!
Вопросы к возможностям оформления текста на Habr, но вы можете предложить свой вариант :)
Единственное место, где используется слово "таск" — ваш комментарий :)
Дело не в инструментах, а в подходах и командной работе.
Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.
В заглушке предусмотрены разные кнопочки или их отсутствие, и может не быть цены.
Это гибкий шаблон для применения в разных ситуациях, предусматривающий много разных состояний и кейсов
Абсолютно согласна, от проекта и от того насколько атомарны компоненты. Атомарность это ещё одна большая и болезненная тема дизайна и разработки интерфейсов в принципе.
Мне лично слова "глупый" и "тупой" кажутся наиболее подходящими, потому что отражают отсутствие привязки к контексту. Всё-таки "простой" это немного о другом. Но тут как вам удобнее))
Да, буквально там так и написано)) дизайнеры редко используют этот подход, к сожалению
Feel free Можете использовать любое удобное название))
Спасибо за комментарий! Я думаю, вы правы. Большую роль играет атомарность компонентов и сложность в том, чтобы определить, когда делить на компоненты, а когда нет. Бывает и так (и, по моему опыту, это происходит чаще), что код трудно поддерживать потому, что нет возможности поменять несколько мест сразу.
Возможно в случае нескольких проектов на одной библиотеке, стоит смотреть в сторону дизайн-системы и организовывать компоненты на двух уровнях: простые тупые на уровне дизайн-системы и умные на уровне проекта. Как бы библиотека в библиотеке.