Comments 17
Тема абсолютно верная, несмотря на "внушительные" названия типа "ядро", бигдата, сервисы, бизнес-логика, кластеры и прочий бэкенд, именно UI по прежнему съедает бОльшую часть дорогих ресурсов вашей команды
Но agile никто не отменял, не обязательно сразу пилить всю СИСТЕМУ, сделайте хотя бы сборник дизайна типовых элементов UI, без привязки к стеку. Это уже сразу сэкономит десятки дорогих человеко-часов.
Далее, придумайте правила, регламенты, как наращивать эту систему маленькими шажками, экологично, командами действующих проектов, без привлечения выделенных ресурсов. Через год-два глядишь и будет уже что-то серьезное.
проблема размеренного подхода в том что как правила у каждой команды свои релизные циклы и как правило жёсткие. И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз. Так как на это просто может не хватать времени да и думать о том что и как будут использовать другие просто не смогут так как не вкурсе деталей. Предположим начали делать шажками, но систему не только надо создать но и поддерживать, через 2 года вы попадете в точку в которой надо будет ее переписывать.
через 2 года вы попадете в точку в которой надо будет ее переписывать
Боюсь, через такой срок мы туда попадем, даже если выделим на это специальную команду
> И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз
Нужен такой процесс наполнения системы, чтобы он не создавал отдельной проектной команде никакой нагрузки, а наоборот, экономил время: допустим, у команды в спринте есть задачи запилить красную и зеленую кнопки:
1. Смотрим в общем репозитории элементов
2. Красной кнопки нет. Делаем в соответствии с общими гайдами на кнопки(если он есть): шрифт, скругления. Заливаем в общую репу эту красную кнопку.
3. Зеленая кнопка в общей репе есть - берем оттуда готовую.
Да, через пару лет эта общая репа потребует серьезной ревизии, но это куда меньше работы, чем делать все с нуля, собирая требования с действующих и планируемых проектов.
А что мешает на этапе проектирования предусмотреть у компонентов параметры и залить в репозиторий достаточно полную базу различных вариантов? Другим словами, что мешает записывать в кодовую базу не только сам конкретный класс, но и всю сопровождающую его "обвязку", которая всё-равно будет потом возникать по ходу пьесы?
Почему авторы подобных статей (с хорошим внутренним посылом) не любят разбирать конкретные примеры? Статья завершается там, где должен возникнуть рабочий пример.
Лично для меня важная "зацепка" для понимания истинного положения вещей находится вот здесь:
Стекозависимость -— разработанная дизайн система на ангуляре не будет работать на вью или реакте, так как созданные части не будут подходить. Как следствие, вы становитесь заложниками того, на чем у вас создана система. Высока вероятность того, что вам рано или поздно придется переписывать все, даже если будут просто серьезные изменения между версиями того стека, который вы выбрали
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Проблема в том что не существует универсального способа. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Какой калификации сотрудники
На сколько их знания в этой области глубоки и есть ли опыт
Есть ли финансирование данной активности и одобрение руководства так как я знаю случаи когда такое старались провернуть в тихоря.
На сколько большая компания
Как быстро нужен результат
На сколько большое легаси в которое надо будет вживлять данную систему
И это далеко не весь список вопросов, ответы на которые повлияют на выбор сценария реализации проекта или же вообще прекращения активности в этом направлении
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Вывод немного другой. Я сообщил о риске который надо учитывать и построении планов на будущее. Просто если компания не определилась со стеком, то строить систему до решения этого вопроса просто глупо. А что касается чего-то нативного или абстрактного, то нативное будет работать медленнее компонента который сделан на конкретном стеке, а абстрактного то тут вляпываешься в поддержку, читабельность и прочее.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Мне кажется отчасти вы правы, но я не встречал ни одного годного решения которое просто в обращении или хотя бы понятно в использовании. Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками. Если знаете с радостью готов выслушать.
Проблема в том что не существует универсального способа.
Универсальный способ существует и он коротко обрисован здесь мною. Решение известно. Но никто не торопится это решение воплощать.
. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками.
Боюсь, таких решений нет. Хотя, я подозреваю, что в отдельных компаниях имеются внутренние системы, которые в чём-то близки к задуманному.
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
В данном случаи я думаю проблема не в столько в декомпазиции, сколько в том что постоянно меняется задача и оценки. А это значит что не возможно спрогнозировать когда это действительно будет приносить прибыль. Тут же все-таки про бизнес. А в бизнесе если нет сроков то нельзя этим управлять.
... меняется задача и оценки.
Давайте, тогда, рассмотрим какие-нибудь конкретные задачи. Вот была одна задача, а возникла другая... Чтобы оценить сложность.
Давайте, тогда, рассмотрим какие-нибудь конкретные задачи. Вот была одна задача, а возникла другая... Чтобы оценить сложность.
Допустим вам потребовалось сделать новый компонент что является задачей на расширение функциональности в которую входит дизайн, описание и разработка. Но в процессе выясняется что требуется для реализации требуется обновить зависимости своей ui-системы. И как следствие и всех продуктов/ проектов которые используют ее. Вроде обычная рядовая задача по расширению превращается в апдейт. Это как пример, наглядно показывает что простая задача которая на одном продукте бы заняла условно неделю превращается в месяц а то и два с перетряхиванием всех потребителей.
Такой пример подойдет?
В примере должна быть конкретика. Чтобы можно было бы позадавать вопросы и раскрутиться до какого-нибудь приличного уровня понимания.
Какой новый компонент?
А есть старый компонент, который надо расширить?
Речь идёт о пользовательском интерфейсе?
Или это какой-то внутренний процессор?
В сами говорите о наличии зависимостей. Ведь, кто-то допустил эти зависимости. Какие-то зависимости будут всё-равно. И никуда от них не денешься. Но что-то наверняка можно представить таким образом, чтобы не надо было бы много чего править.
Я пытаюсь сходу придумать пример... Что же это может быть? Изменение логики работы какого-нибудь элемента управления? Изменение формы ввода?
Или, вот, на Хабре:
Реализовать способ сворачивания/разворачивания веток дискуссий.
Реализовать удобную печать поста/дискуссии в файл/на принтер.
Реализовать аналог RSS-протокола и соответствующее приложение, которое способно читать ленту сообщений и формировать на конечном устройстве удобное отображение динамически формируемого содержания постов/дискуссий Хабра.
Ок, понял.
Давайте представим что у вас уже есть ui-система. Она написана например на ангуляре 14 версии. У нас есть компонент написанный с использованием moment.js .
Задача, доработать способы отображения этого календаря а так же провести оптимизацию для скорости. Или даже лучше сделать что-то такое что базовым функционалом moment.js решить очень сложно или же просто не возможно. В идеале еще поднять перфоманс.
Первым делом , мы такие смотрим что классно было бы просто поднять версию ангуляра например до 16, что дало бы ощутимый прирост производительности так как там появились standalone компоненты что позволят нам сократить размер билда и в целом выкинуть модули как таковые.
И вот мы такие радостно запускаем npm update и вуаля нам очень повезло и все обновилось и даже не возникло конфликтов с версиями. Мы радостно запускаем npm run build/npm run start и видим что мы в глубокой Ж....
Так как moment.js стал deprecated мы лезем к ним на сайт а там душераздирающее сообщение, что они слёзно извиняются но проект закрыт. А так же они рекомендуют использовать новый, современный, легкий date-fns.js. Мы такие радостные бежим туда и читаем документацию, в надежде на то что нам просто надо будет поправить импорты и все. Дело сделано.
После прочтения мы начинаем лысеть, так как понимаем что синтаксис другой, название функций другие, способ задание и в целом все другое.
А теперь мы садимся и начинаем считать трудозатраты всего этого упражнения. Вот перечень работ которые нам потребуется проделать:
Удалить везде где в системе использовался
moment.jsПоменять все входные параметры которые были завязаны на формат
moment.jsПереписать все функции в которых был задействован
moment.jsвключая вспомогательные.Написать вагон новых тестов для покрытия того что получилось.
Вроде не так сложно да? А теперь давайте представим как вы это будете объяснять бизнесу(продуктам/ проектам) которые используют вашу ui-систему.
Что им придется потратить +100500 человека часов что бы обновиться на новую версию. Так как потребуется перелопачивать все продукты полностью из-за того что плодить зоопарк из зависимостей вам ни кто не даст, а так же не получится остаться на старой версии так как ее поддержка прекратится.
В таком кейсе как вы считаете ui-система хорошо?
По мне так если бы ее не было то каждый продукт мог постепенно переехать на нужную версию когда им было бы удобно. Пришлось бы просто контролировать тех долг и пушить его, что в разы проще.
Сейчас все начнут накидывать что неправильная система и прочее. Но идеала не существует. Пример немного утрирован но мне кажется доходчиво показывает риски связанные с такой махиной как ui-система.
Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Звучит страшновато. Не лучше ли выбрать, например, формат SVG? Или HTML+CSS. А трансляцию в стекозависимый вариант, ручную или автоматическую, оставить уже на совести проектной команды. Всяко такой подход уже упростит им жизнь.
А у кого можно узнать, почему в названии статьи четвёртый символ — пробельный? @Evil_Evis
UI-система или хроники Хаоса