Кто такой фронтендер

Кто такой фронтендер Подготовили банк собеседований по фронтенду . У ребят, которые только начинают свой карьерный путь нет представления о рабочих процессах фронтендера. Исправляем. Представьте, что вы зашли в ТГ. Все эти кнопки, меню, переписки, поля для ввода — всё, с чем вы взаимодействуете, это и есть фронтенд. Такая штука в вашем телефоне называется приложением. На компьютере — это веб-приложение. Задача фронтенд-разработчика — создать его интерфейс. Наш чат карьеристов . Фронтендер не просто «рисует» кнопки, а программируем их логику. Чтобы сообщение не просто появлялось в поле, а отправлялось и мгновенно доставлялось собеседнику. Обычно в проекте есть два основных «лагеря»: фронтенд (то, что видит пользователь) и бэкенд (то, что работает на сервере). Фронтенд-разработчик, неважно, пишет ли он под веб, телефон или даже для умного холодильника, делает так, чтобы у вас был удобный способ «общаться» с бэкендом. Ведь вы же не отправляете HTTP-запросы вручную, чтобы загрузить фото? Всё делается через интерфейс. А теперь — как это выглядит изнутри, на проекте. Есть такая штука — Jira. Это такая продвинутая система для задач. Представьте себе доску со столбцами: «В плане», «В работе», «На проверке», «Готово». Задача — это карточка. Ты берёшь её из «В плане», перетаскиваешь в «В работе», а по завершении — в «На проверке». Откуда задачи берутся? Их создают бизнес-аналитики и разработчики. Если бизнес хочет, скажем, «сделать стул», аналитик подробно расписывает, как этот стул должен выглядеть и работать. Все эти задачи складываются в бэклог — большое хранилище идей и планов. Периодически команда проводит груминг — встреча, на которой решают, какие задачи из бэклога готовы к работе. Задачи часто объединяют в Эпики — это большие темы. Например, эпик «Система заказов» может включать в себя десятки задач для дизайнеров, фронтенда и бэкенда. Допустим, мне нужно «Сделать страницу просмотра заказа». В задаче обычно есть две ключевые ссылки: на дизайн в Figma (где всё показано с точностью до пикселя) и на техническое задание в Confluence (где расписана логика). Сначала я внимательно изучаю дизайн: как страница выглядит при разных состояниях (заказ оформлен, отменен, доставляется). Если что-то непонятно, иду в документацию. Если и там нет ответа — пишу аналитику или тимлиду. Я проверяю, готовы ли на сервере все нужные для страницы данные. Бывает, что бэкенд ещё не доделал свой кусок. Тогда я ставлю его в известность и временно переключаюсь на другую задачу. Когда всё готово, открываю редактор кода и терминал. Первым делом обновляю основную ветку develop (команда git pull), чтобы работать с самой свежей версией проекта. Затем создаю новую ветку для своей фичи (git checkout -b feat/order-view-page). Написал код — сохраняю изменения (коммит) с понятным сообщением, например, «feat: add order view page». Проверка кода (Code Review). Я загружаю код в общий репозиторий (у нас GitLab) и создаю Merge Request (MR) — запрос на добавление моего кода в develop. В Jira я перемещаю задачу в «В ревью». Коллеги смотрят мой код, оставляют комментарии. Мы обсуждаем, я вношу правки. После одобрения (апрува) код вливается в основную ветку. Потом наступает очередь тестировщиков. Они ищут баги. Если находят — создают новую задачу, и я её исправляю. Готовый код по цепочке выкатывается на тестовые серверы через пайплайн — автоматизированный процесс сборки и развертывания. Если пайплайн «падает», мы ищем причину и чиним. @chad_protocol