Чем frontend разработчик занят на реальных проектах?

Question

[helpmeplease196]

Я junior frontend, опыт чуть больше года, работаю в одной команде, не меняла место. И заметила, что основная часть задач - инфраструктурная. Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД. Я понимаю, что это важно, но вгоняет в некое уныние, так как я шла в frontend, что бы работать с интерфейсами, пользовательским опытом, макетами.
Для себя учу библиотеки анимаций и прочее. Но в работе это не применяется, максимум мелкие изменения в дизайне. Остальное - работа с внутрянкой, оптимизация, скорее работа с bff.

Так везде, или имеет смысл просто сменить место?

Comments

[Adamos]

Есть вариант поискать места в проектах, где можно приложить интересные интерфейсы, потратить на это время (возможно, свободное) и попытаться аргументировать пользу этой работы перед руководством.
Оно же тоже не на скрижалях упало, имеет кучу своих проблем и может просто не видеть такого вектора развития.

[Ziptar]

UI/UX дизайнер это несколько отдельная специальность.

...
Хотя лично у меня скоро будет нервный тик от любителей играться с интерфейсами

[VoidVolker]

Ziptar, не у вас одного, не у вас одного )

[Дмитрий]

Обычно двигать пикселы должен реально, и играть со шрифтами, главное не проиграть)

[mayton2019]

Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД.

OLAP CUBE, оптимизация запросов к БД - это очень скиловые задачи и кому попало их не дают.

Возможно у ваших боссов действительно сложилось не то понимание ролей в команде.
И есть повод об этом поговорить. Но сами по себе задачи - не простые.

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

[Vitsliputsli]

mayton2019, плюс в резюме эт хорошо, но автору хочется фронтенда. И, когда она пойдет менять работу, рассказывать на собеседовании на фронта про оптимизацию запросов в бд, про кубы в аналитике, она либо получит отказ, либо ее резюме отправят в бекенд команду.
Ладно там ci/cd, совсем не обязательно для этого держать человека. Ладно тесты, хотя не понятно что это за тесты, и что значит "настраивать" их. Но olap кубы и оптимизация запросов это совсем не про фронт.

[historydev]

[РОМАН ШТЕФАНОВ]

Если тебе дают на работе задачи которые ты не знаешь как делать, то по сути тебе оплачивают обучение, наоборот надо держаться за такое место.

Answer 1

[Виктор Кожухарь]

С резким ростом популярности React Server Components и Next.js в последнее время происходит некий сдвиг в понимании, что такое фронтенд.
BFF уже почти становится неотъемлемой частью "фронтенда", и становится обременительно разделять браузер и сервер на разные команды.
На Западе, вообще, уже очень давно и макетами, и вёрсткой, и анимациями очень часто занимается один человек - дизайнер, фронтендеры занимаются связкой браузер + BFF, а бэкендеры занимаются более сложной бизнес-логикой.
К тому же, джуниорам зачастую дают те задачи, которыми сами не хотят заниматься, и на что нет времени. Т.е. это что-то занудное, работа с legacy, передвижение кнопки на 5px влево и т.д. Крайне редко джуниорам дают интересные творческие задачи. Не факт, что вам на новом месте не дадут такие же неинтересные задачи.
Вы можете либо молча сильно стараться в надежде, что вам потом дадут что-то интересное, заметив ваше рвение, либо, лучше всего, пообщаться по-человечески с коллегами и начальством, объяснив, что вы рветесь в бой, а вас в тылу держат. Попросите рассказать об их планах на ваш счёт.
Не исключено, что у вас как раз хорошо получается "Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД", и поэтому вам эти задачи и дают)
В общем, человеческое общение с коллегами очень часто решает проблемы.
Если же вы к ним придёте с открытой душой, а вас токсично отошьют, вот тогда подумайте о смене работы.

Comments

[Vitsliputsli]

BFF это забавная штука, столько усилий положено, чтобы любой api делал полностью независимыми взаимодействующие стороны, и вот опять, а давайте мы чутка вернемся к монолитному решению, совсем чутка, так чутка, что теперь нельзя менять языки разработки, да и вообще один реп это лучшее решение. Ну-ну, всеми силами пропихнем ноду на сервер.
Но хоть и bff, кубы и оптимизация запросов в бд это совсем не про фронт. И там может оказаться, что бека нет, остальным не хочется этим заниматься и спихивают на того, кто не смог отказаться.
А поговорить, всегда хороший вариант.

[Виктор Кожухарь]

Vitsliputsli, BFF - это про сессии, httponly secure cookies, правильный csfr.
Если бы вы знали, как безответственно некоторые фронтендеры относятся к безопасности, храня самые секретные токены где попало, то не говорили бы такое про BFF.
Второй пункт - SSR. Две первые буквы в HTTP обязываются Hyper Text. Разметка передаётся быстро, сразу вставляется в DOM без идиотского медленного парсинга километров JSON. Состояние сессии хранится только в одном месте - на бэке, таким образом не надо тратить нервы на затратную синхронизацию состояния при помощи монструозного пожирания памяти.
Третий пункт - это скорость разработки. Фронтендеру при разработке MVP иногда надо менять API по нескольку раз в день. Я, как бэкендер, послал бы его на три буквы и требовал бы тикетов от менеджера, потому что у меня и так делов полно. Это сильно замедляет разработку.
И т.д., и т.п.

[Vitsliputsli]

Виктор Кожухарь, ни одно буквенное сочетание не вылечит безответственность, хоть на беке, хоть на фронте, но речь не об этом. Чтобы рендерить на сервере, не нужны новые буквы, как не нужны они были 20 лет назад. Просто нужно понимать, что оба варианта имеют свои плюсы и минусы. Магия производительности монолита притягательна, но нужно принимать риски, т.к. api для веб придумывали не на пустом месте.
Парсинг json - это очень быстро, т.к. формат очень простой.
Бекендеру менять api по нескольку раз в день не нужно, т.к. есть моки.
А вот пожирание памяти - это проблема, конечно, тут правильнее было бы нормально работать с памятью, но с нуля это никто делать не будет. А держать только то, что нужно, вполне реально для большинства случаев.

[Steel_Balls]

Боже, вспомнил новое модное слово - "Server-side-rendering"...
И опять вернулись ко временам ASP, PHP, Perl на 25-30 лет назад, где весь HTML генерился на сервере и отдавался клиенту. У которого был отключен JavaScript в целях безопасности (тогда ещё HTTPS не придумали)

[Виктор Кожухарь]

Steel_Balls, А я вам объясню, как это получилось.
Чтобы понять, почему от полного рендеринга на сервере перешли к созданию монструозных SPA, надо понять, что в те годы распространённость быстрого интернета была всё ещё крайне мала, а вот компьютеры стали уже достаточно быстры, да и памяти у них стало значительно больше. Поэтому, с ростом сложности проектов и динамики на страничках SSR начинал тормозить из-за того, что большое количество одновременных запросов не укладывалось в трафик. Решением этого стало кэширование данных в браузере, перенос значительной части функционала в SPA, а общение с сервером стало редким и передавалось мало данных. И это была революция для того времени, ведь можно было пользоваться сложным сайтом даже при наличии 3g модема на телефоне в глухой местности.
Но не будем забывать, что это привело к такому росту сложности браузерного фронтенда, что совсем скоро браузеры превратились в основного пожирателя памяти компьютера. Наличие двух образов данных в браузере и на бэкенде неминуемо привело к росту багов из-за их неверной синхронизации и из-за того, что данные иногда по-разному валидировались в браузере и на сервере. По этому поводу уже давно шло ворчание в соцсетях.
И вот... Случилось... Интернет стал быстрым почти везде, 4G и 5G сделали смартфоны иногда даже быстрее домашнего интернета. Серверы переехали в облака и стали невероятно быстрыми. В результате, уже классические SPA превратились в анахронизм, от которого вреда стало гораздо больше, чем пользы. И люди стали возвращаться к тому, что гораздо лучше и проще - к SSR. Вот и всё.

[Steel_Balls]

Виктор Кожухарь, да, мне всегда не нравились эти фронтендерские монстры, которые жрали всю память, стоило только открыть страницу их сайта. На что в ответ от соевых фронтендеров с капучино в руках я слышал: "А ты купи себе комп помощнее и побольше памяти". Ага, 32 гига оперативки им стало мало, уроды.
Фууу, мерзость.
Пусть поучатся на 64k Demoscene

[Vitsliputsli]

Виктор Кожухарь, SPA это ни разу не про медленный интернет. Это полноценное приложение, которое еще нужно закачать на клиентскую машину, и тут клиент прям охренеет, как это долго. Но даже если все залилось и закешировалось, намного ли меньше будет ajax-запрос SPA? Вспомните какую-нибудь табличку с данными, придет она оформленная в несколько тегов html, или данные в json, а в этих данных будут еще и словари, что отображаем/не отображаем, что можно сортировать что нельзя и т.п. Да и после сжатия разница скорее всего будет несущественной.
Тут больше сыграло то, что сняли нагрузку с сервера и перекинули ее на клиентские машины.
Индустрии всегда насрать на ворчание в соцсетях. И уж тем более, когда ворчат из-за того что ручки кривые. Не, серьезно, наличие нескольких "образов данных" - это повседневность любой мало мальски сложной современной архитектуры, жаловаться на это, это прям...
Субъективно, я не вижу что "люди стали возвращаться". Когда бекендер делает в одно лицо и не хочет тащить монструозный фронтовый фреймворк - да, но так было всегда. А в общем, реакт уже становится стандартом, про vue забыли, и даже ангуляр какимто боком прорастает то тут, то там. Хотя более несуразной вещи я не видел. Но, это все, конечно, субъективно.

Answer 2

[Gip]

Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД

- это важно для фронтенда знать, что такое просто есть) явно вас не тем загружают.

Comments

[helpmeplease196]

А чем обычо загружают?) если брать среднее по рынку?
У нас всё приложение некий дашборд с инфой, фильтрами, выгрузкой. И иногда падают задачи добавить кнопку, поправить фильтры( м интерфейсом работала о силы раз 10 за год). А в остальнои - всё настройки и оптимизации. Вот я и не пойму везде оно так или надо бежать отсюда

[Vitsliputsli]

helpmeplease196, везде по разному.
А чем остальные фронтендеры занимаются? Добавляют все вместе 1 кнопку раз в месяц?
Очевидно, если нет задач по фронту, то и развития по нему не будет. Хочется развиваться во фронте ищите проект, где есть разнообразные задачи.

Answer 3

[ThunderCat]

И заметила, что основная часть задач - инфраструктурная.

Такой работы всегда много, но есть нюансы.

Настройка тестов

Да, это в любой разработке будет, не только во фронте

CI/CD

Сомнительно, но окэй, знать это очень желательно, но в крупных проектах этим занимается девопс, как минимум настраивает скрипты. В малых компаниях это раскидывается на разрабов, есть такая практика.

OLAP CUBE, оптимизация запросов к БД.

А это вообще чисто бэкендерские заморочки, конечно никто бить за понимание таких штук не будет, но в целом фронту это не особо важно, у него должно быть расписано апи/эндпоинты и чего туда пихать и что получать. Уж оптимизацией запросов чистый фронтендер точно не обязан заниматься.

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

Answer 4

[Belvarm]

Если вы недовольны текущими задачами, то обсудите их с вашим прямым руководителем, узнайте какие дальнейшие планы или запланированный пул задач. Если уж перспектива вас не устраивает, то меняйте место работы.

Answer 5

[alexalexes]

В вашем проекте, скорее всего основная бизнес-логика сосредоточена на беке, а на фронте довольно тонкий клиент.
Поэтому все правки там, где основной функционал.

Ищите проекты с SPA интерфейсом, там утоните в сопровождении формочек.
Либо компанию, которая делает мелкие сайты на потоке.

Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД

Ну, или забудьте про интерфейсы и развивайтесь в QA, аналитику, в администрирование базы данных, интеграцию проектов, в linux администрирование. Такие спецы нужны чаще и за дорого, нежели, кто проектирует формы.

Answer 6

[VoidVolker]

И заметила, что основная часть задачь - инфраструктурная. Настройка тестов, CI/CD, OLAP CUBE, оптимизация запросов к БД

Вполне нормальное явление, когда часть времени разработчик выполняет не профильные задачи для него - особенно, если он с ними успешно справляется, а другим некогда или просто нет отдельного человека на эти задачи. Такое очень часто в любом проекте случается. Квалифицированных специалистов всегда нехватает. Главное, чтобы работодатель оплачивал решение этих задач и они были согласованы между работодателем и работником.

имеет смысл просто сменить место?
...
мне нравилось работать именно с интерфейсами, было бы круто хотя бы 50% таких задач

В вашем случае имеет смысл пообщаться с начальством и спросить на счёт профильных задач. Вполне возможно, что сейчас их просто нет - вот вам и дают простые задачи, которые легко делать по пошаговому мануалу, чтобы не тратить ваше оплаченное время в пустоту. А потом как появятся задачи - так ими вас завалят с головой. Если вас всё устраивает на текущем месте работы - то и продолжайте трудиться и дальше. Знания бесполезными не бывают. А вот если у вас нет желания работать над неинтересными для вас задачами, возможно, стоит обсудить с работодателем о сокращении вашего рабочего времени в его текущем проекта, чтобы вы могли переключиться на другой более интересный и профильный для вас проект на время, пока нет задач для вас.