Transcription
У вас сейчас есть возможность посмотреть доклад, который потом люди только за большие деньги посмотрят. Вот.
>> Да.
>> Так, зелёный магазин ждёт.
>> Так что доставайте камеры и перепродаём.
>> Давай.
>> Ты будешь переключать?
>> Да.
>> Да, я.
>> Ну давай. Хорошо.
А, итак, ребят, всем привет. Перейдём от мира тестирования к миру фронтенда. Почему-то Олег разработку пропустил. Вот поэтому я возьму как бы бразды правления, да. И во фронтенде тоже есть свои боли, проблемы, с которыми сталкиваются разработчики. И одна из этих болей - это то, что нам приходится верстать вообще много верстать сложный дизайн, UI там и так далее. На это уходит куча времени постоянно. И, а, с другой стороны, сегодня бурно развиваются и технологии, улучшаются модели, улучшаются возможности кодагенерации, генерации текстов и вообще и сейчас внедряется повседневно в нашу жизнь более плотно, и жизнь уже невозможна без него. И возникла идея, что если нам использовать вот эти возможности Ии для генерации нашего UI, вообще, что из этого может получиться? Будет ли вообще автоматизация? Давайте посмотрим.
А для начала давайте ещё немного познакомимся. Меня зовут Олег Сикирюк. А как переключать-то? Не всё, как обычно.
>> Вот так вот, что ли?
>> Это так неудобно нихера.
А меня зовут Олег Кирюк. Я разрабатываю мобильные веб-приложения. А в последнее время фокус больше именно на мобилку, так как она, ну, там в тренде сейчас, да, модно говорить. И мы очень много верстаем, э, разрабатываем сложный UI. Поэтому мне вот эта проблема, вот эта боль, она как никому больше знакома. Вот. И в последнее время, конечно, цепляет вот эти все штучки иишные, но с целью в первую очередь для автоматизации, повышения скорости и вообще комфорта разработки. Так. Так вот.
А, ну давайте для начала ещё посмотрим на те боли, которые возникают у разработчика при разработке UI. А всё у нас начинается с того, что у нас есть дизайн-макет, который разрабатывает дизайн, дизайнер. И в этом макете зачастую у нас содержатся какие-то общие цвета, палитра, тема, а дальше отступы, всякие тенюшки и, конечно же, компоненты, их состояния, все те правила, что задумал там дизайнер, вот эти все взаимосвязи, они есть. И задача разработчика сверстать этот макет, собственно, разработать UI, чтобы всё было красиво, классно и реализовывало задумку самого дизайнера. И здесь начинаются проблемы, что нам же надо все эти цвета скопировать из этой дизайн-системы, положить их в код также с отступами и при этом ещё не ошибиться в этом, а потом у дизайнера спросить, да, что он там задумал, какие у него там правила и так далее. Всё это надо уточнить у него, спросить. И, конечно же, здесь можно ошибиться. Здесь вообще легко ошибиться в этом во всём. И всё это ведёт к снижению нашей мотивации в целом продуктивности вообще. И, э, в целом, ну, вот это всё, это рутина для нас. Это рутинные операции, а нам хочется заниматься творческими и какими-то архитектурными задачами, вот, а не вот этим вот всем вот просто, э, то есть большая часть времени уходит не на разработку, а на синхронизацию с дизайном. с дизайном, то есть переносить вот эти все цвета, стили и так далее. Поэтому нужен какой-то способ автоматически всё это понимать, ээ изменения в дизайне подхватывать и, соответственно, всё это обновлять.
А раньше было ещё хуже. Раньше просто дизайнер рисовал макет в картинке, передавал его разработчику, и разработчик уже там либо на глаз, либо с помощью линеек переносил все эти цвета, отступы в код, что, конечно же, не очень соответствовало, да, вот исходной задумке. Далее у нас появляется уже, ну, происходит прорыв, так сказать, да, появляются облачные инструменты, которые позволяют разработчикам, дизайнерам работать совместно над единым макетом. Это, конечно, был такой вауэффект, да, что вот такого не было и все могут смотреть этот дизайн и понимать там, что есть. Далее появляются уже инструменты по частичной генерации кода, да, всякие библиотеки, программки, которые позволяют вам подключиться к вот этой облачной системе, оттуда всё скачать и переложить на код. А сегодня же появляются различные AI инструменты, агенты, чатботы, которые как раз могут взять часть проблем на себя, да, какую-то часть автоматизировать. Вот. И нетрудно догадаться, что в будущем мы идём уже к более полной автоматизации, когда яиш берёт на себя уже всю ответственность по пониманию, что нам надо сгенерировать, зачем и ещё проверить это всё. Вот к этому, я думаю, мы идём. А, то есть здесь разработчик почти не будет участвовать, может быть, только будет проверять то, что нам нагенерировалашка.
Так, что? Что? О, а, но самое смешное, что в дизайн-системе уже содержится вся та информация. Что нужна разработчику- это все цвета, отступы, компоненты, вот эти все хитрые взаимосвязи, слои, э, которые нам просто надо взять и перенести в код, да. Вот зачем нам изобретать велосипед, там спрашивать у дизайнера, типа, а что ты имел в виду, э, когда ты сделал вот этот компонент, да, что он значит там, э, вот и ключ ко всему этому - это вот как раз применить м технологию Ии, да, а ведь Ии очень хорошо понимает вот эти все взаимосвязи. закономерности, может сделать выгрузку, написать код и провести все эти операции. Поэтому попробуем вот применить и, да, для решения нашей задачи.
Так, а давайте более детально посмотрим, как происходит процесс преобразования из нашего дизайнмакета в наш код. А у нас есть некоторый дизайн-макет. Он у нас будет в Пикса. Кстати, кто-нибудь работал в Пикса? Есть опыт? Ни у кого. Все, все в Фигме, наверное, 100%.
>> Говорят, что фигло,
>> да? Вот фиг сейчас заблокировали. Что делать? Вот использовать пик.
>> Дальше дальше пену.
>> Хотя, ладно, Олег, я узнал, что я пользуюсь пиксом.
>> Да, чисто случайно.
>> А сейчас
>> я не смотрю там, куда мне?
>> Да нет, там всё это доступно, да.
Вот, короче, у нас есть вот дизайнмакет, какая-то дизайн-система, которую там дизайнер сделал. И на выходе нам надо получить вот эти все компонентики, экраны, всё, как это по дизайн-системе. И как вы думаете, что здесь вот какой секретный ингредиент надо добавить, чтобы сделать вот это преобразование?
>> Система.
>> Да, всё правильно.
Так. Так. Вот. А, да, здесь у нас выступает яишко, то есть у нас есть лмки какие-то, мы выбираем какую-нибудь модельку. И ещё мы используем MCP сервер для удобства, который нам Pixa тоже предоставляет из коробки для взаимодействия с опишкой Пикса, чтобы извлекать все компоненты и а уже дальше их передавать на генерацию. Ну и ну и вишенка на торте. Мы ещё попробуем всё это автоматизировать в процессах CCD на примере гитlлаба.
Итак, возьмём какую-нибудь дизайн-систему, вот какую-нибудь простенькую, в которой есть, э, цвета, а, стили для текста. Вот они все перечислены. И возьмём какой-нибуд простенький компонентик, допустим, кнопочку. Вот она здесь есть. Может быть, это и не такой простой, да, компонент, оказывается. А мы видим несколько различных вариантов этой кнопки для различных случаев, да, там кнопочки бывают succes, там erro. А, большие, маленькие, с иконками, без иконок и так далее. И мы попробуем всю эту штуку реализовать, каким-то образом выгрузить все эти цвета, стили и положить их в код.
А ещё ещё пару слов о Pix MCP. Э, как я уже говорил, это сервер. Он как раз является таким промежуточным звеном между вашей Олэмкой и Pixi, чтобы доставать какие-то данные. А общение происходит под капотом, как обычно, и происходит в формате запрос-ответ. То есть мы, допустим, формируем запрос там, э, предоставь такой-то компонент. И на выходе мы получаем ответ, что вот такой-то компонент, у него есть такие-то стили, э, свойства и так далее, которые можно использовать. Э давайте начнём с базового. Ээ, есть в Пикса есть возможность задавать глобальные переменные, так называемые, и в них обычно дизайнер хранит, а, цвета, стили текста, дизайнтокены, чтобы потом дальше их использовать в своих компонентах и, соответственно, менять. А вот и дальше мы можем уже с этим работать, уже можем выгружать. Для этого мы выбираем лмку, подключаем к ней mcпишку и уже можем писать прот. А прот, ну, буквально можно написать: "Сгенерируй мне flatter dark cд для моей дизайнсистемы". Вот тебе ссылка на дизайнмакет. И просим, что мы просим извлечь, это цветовую палитру, стили текста, дизайнтокены. И всё это нам нужно хранить каким-то образом глобально, чтобы у нас был доступ до а из других компонентов. В результате мы получаем вот такой код. Ээ, видим, что у нас создаются классы с константами, да, которые мы можем уже потом подключать в наших компонентах других, ээ, в коде и использовать. А, кроме того, все эти файлики, они сохраняются вот в кор всё в одном месте лежит. То есть мы можем понимать, что здесь у нас вот эта наша тема, да, в этой папочке вся наша тема, и потом её использовать.
Итак, мы сгенерировали базовые переменные, выгрузили. Теперь мы можем приступить к генерации простого простого компонента кнопки. А здесь мы также пишем промт. Можем сразу написать нам надо сгенерировать виджет на основе дизайн-системы. При этом отмечаем, что нам надо использовать вот эти все глобальные цвета, стили, а, отступы, которые мы получили на прошлом этапе. Ну и плюс ещё учесть, что вот кнопка может быть нескольких вариантов, да, она может разделяться по ролям, то есть могут быть sucess кнопки, там critical, да, когда ошибка, допустим, а могут они разделяться по размерам, вариантам и другим параметрам. И в результате нам генерируется вот такой виджет. Это универсальный виджет кнопки. И здесь мы можем увидеть, что у нас создаются перечисления для как раз поддержки вот этих всяких вариантов. Вот они, да, там по ролям, по вариантам, по размерам. И они задаются в качестве входных параметров к нашей кнопке. То есть мы можем, меняя вот эти параметры, получать ту или иную кнопку. Вот так вот всё легко и просто. А также мы можем увидеть, что мы используем, ну вот здесь, наверное, плохо видно, э, используем как раз наши дизайнтокены, которые мы как раз вот выгружали на прошлом этапе. Так. Ой, я пропустил. Может назад? Вот.
В итоге мы получаем, э, полный UI kit, можно так сказать, да, с нашими стилями общими. Вот у нас и можем даже сделать такие демоэкраны, на которых вот вывести все наши переменные, да, так и вот в какой-то компоненте кнопки, допустим, и все варианты перечислить здесь. Ну, кроме того, можем задавать различные параметры и получать ту или иную здесь кнопку. Но стоит отметить, что генерации нам недостаточно. Ведь у нас продукт развивается, дизайнер постоянно что-то меняет, переделывает, и появляется проблема, что вот дизайнер что-то изменил, там цвет, токен, стиль какой-нибудь, и код у нас перестаёт быть консистентный, да, вот с этой с этим дизайн-макетом. Вот. И что делать в этом вообще случае, да? Вот регенерировать всё, но как-то это странно, да, и излишнее. Ведь у нас могут пропасть наши доработки какие-то, да, потому что у нас затрётся просто и всё генерации. Вот. Другой способ - это искать вручную, как-то вручную сравнивать там с дизайнмакетом, что поменялось. Вот как-то это не очень, да. Поэтому немного подумав, можно придумать вот такой алгоритм. А, то есть дизайнер меняет макет, мы выгружаем, а, изменения, которые, э, у дизайнера. Дальше вот самое главное, их надо как-то проанализировать, то есть понять, что что за изменения, а их сгруппировать и самое главное понять, на что эти изменения влияют, на какую часть кода, чтобы потом точечно перегенерировать именно те части, а, которые у нас изменились. Далее у нас происходит обновление кода. И ещё важно нам после всего этого проверить, что у нас всё верно сгенерировалось по нашем нашему дизайнмакету.
А давайте разберём эти части более детально. И самое главное - это вот получить нам все эти изменения, которые у нас есть в дизайн-макете. И, ээ, первое, что приходит на ум, просто взять вот эти все изменения, да, и просто сделать джесончик такой вот. Но здесь стоит учесть, что в дизайнпроекте могут быть такие вещи, которые для нас незначимы. То есть, допустим, наименование слоёв, там, а, порядок порядок этих слоёв. Вот для нас это не особо значимо. Также дизайнер может что-то подвинуть там на несколько пикселей, и нам эти тоже изменения не нужны. Поэтому мы приходим к понятию семантического дива или дизайндива, так сказать, в котором мы видим только значимые изменения и понимаем только то, что у нас изменилось и почему и всё. То есть дизайнди - это больше не про сравнение символов, а про сравнение смыслов. То есть там только значимые для нас изменения. А как представить себе вот этот диф на практике? Ф - это просто джейсончик. Вот, допустим, Ой, а можешь назад? А, допустим, у нас дизайнер поменял цвет или радиус, да, и мы видим вот эти изменения. Всё наглядно здесь и прозрачно. Также и с компонентом тоже мы видим целую группу свойств, которые поменялись.
>> А, и дальше вот мы получили вот этот див. И нам ещё нужно посчитать, а, так называемый импакт. То есть он показывает, на что повлияли эти изменения, то есть какие именно компоненты у нас затронуты. И это тоже у нас джесончик. Э-э, у нас есть sumary с общей сводкой, что поменялось и с изменениями. Вот у нас поменялись токены и на какие компоненты у нас сафектила. Вот такая информация. И дальше мы уже можем начать перегенерацию нашего проекта. Вот берём тот див, который у нас есть с изменениями и импакт, э, в котором содержится информация о том, на что повлияли эти изменения, и делаем перегенерацию. А из плюсов здесь то, что мы перегенерируем точечно, то есть то, что изменилось по макету. И при этом мы не затрагиваем никак ручной код. Ручной код.
И последний этап - это нам надо всё проверить, что у нас действительно всё как по дизайн-макету задумано сгенемировалось. А для этого мы повторно запускаем код gгen, запускаем станализ для отлова различных ошибок, запускаем дальше goldн-тесты, так называемые это скриншотное сравнение, скриншотное тестирование, чтобы понимать, что у нас всё это пиксель-пиксель, как как сказать. Вот. И как раз flatter Dart предоставляет такие инструменты для кодагенерации, для анализа, для запуска goldн тестов.
Дальше мы можем пойти ещё лучше и вообще автоматизировать всю эту историю э на примере процессов CCD в Гитлабе. Кстати, кто-нибудь из вас работал в Гитлабе? Есть опыт. Во, видишь, нормально. Вот. А, ну тут повторю, наверное, всё в Гитлабе, ну, основные процессы сборки происходят в пайплайнах. И чтобы нам создать такой пайплайн, нам нужно сначала создать конфиг, в котором детально описать, какие у нас именно этапы будут будет проходить этот процесс. А или так называемые джобы. То есть джобы - это такие единицы, которые выполняют какое-то определённое действие и имеют свою зону ответственности. Так, у нас есть джбы по получению изменений из дизайнмакета по дальше по перегенерации того, что изменилось, проверка. И в конце мы получаем merch requкст в итоге, который отправляется разработчику на финальное реви. Вот как раз пример такого мрс реквеста. Здесь у нас детальная информация, да, что у нас поменялось, наши изменения и разработчику нужно провести здесь финальное ревью. и либо закоммитить, либо он может ещё и сам это всё подправить, если что-то у нас поломалось.
Итак, что у нас что это нам даёт? Да, немножко таких итогов. Ну, во-первых, очевидно, а вот эта вся генерация, она происходит быстрее, ведь яишко у нас там за секунды, за минуты генерирует код, что значительно быстрее. А, и так как это происходит автоматически, то у нас уменьшается риск ошибок и повышается шанс, что мы, а, достигаем больше соответствия нашему дизайну. Ну и плюс у нас чёткий пайплайн, э, который делает по этапам нашу работу, тоже немаловажным. Вот. И главное здесь это то, что у нас становится меньше рутины и больше уверенности, что мы доставляем ценность пользователя.
Но как и в любом деле, есть проблемки небольшие, да, в том числе и с иишкой. Иишку стоит рассматривать как мощный инструмент, но не замена самого разработчика. А возникают различные проблемы, например, с сложными компонентами, нетипичным UI, именно по точности генерации. Возможно, какие-то ошибки, некорректные, какие-то отклонения и так далее. Вот. Кроме того, пока что необходимо нам проверять то, что нам нагенерила ишка. чтобы не пропустить какие-то важные изменения. Ну и, наконец, Иишка может галлюционировать могут быть какие-то у неё фантазии, там она может что-то насочинять, что не соответствует реальности. Либо ещё были такие случаи, когда она ходила просто по кругу, э, решая проблему. Вот. В общем, здесь главное правило, что как бы Иишка генерирует, да, код вроде всё проверяет, но важно за ней тоже ещё раз всё это перепроверить, чтобы не пропустить что-то важное. что-то важно. Ну, может быть, в будущем это уже изменится и нам меньше стоит проверять или вообще не проверять. У меня на этом всё. Спасибо за внимание.