Фронтенд-разработка — это процесс создания клиентской части(сторона, которая потребляет сервис) программного продукта, с которой непосредственно взаимодействует пользователь.

Это “лицо” приложения: всё, что пользователь видит в браузере или на экране смартфона, всё, на что он нажимает, и вся информация, которую он получает.

Фронтенд-разработчики превращают статические дизайн-макеты и спецификации в живой, интерактивный и работающий интерфейс.

Цели и Назначение этапа

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

Ключевые задачи:

  1. Верстка интерфейса: Перенос визуального дизайна из макетов в код (HTML/CSS), обеспечение точности реализации.

  2. Реализация интерактивности: Программирование поведения интерфейса (реакция на клики, ввод данных, анимации) с помощью JavaScript.

  3. Взаимодействие с бэкендом: Отправка запросов на сервер и отображение полученных данных.

  4. Управление состоянием: Отслеживание того, что происходит в приложении прямо сейчас (пользователь авторизован? корзина загружается? есть ошибка?).

  5. Адаптивность и Кроссбраузерность: Обеспечение корректной работы интерфейса на разных устройствах (телефоны, планшеты, десктопы) и в разных браузерах.

Входные данные

Разработка фронтенда начинается при наличии следующих артефактов:

  • Финальные Дизайн-макеты (Figma): Визуальный эталон всех экранов и состояний.

  • UI Kit / Дизайн-система: Набор готовых компонентов (если есть).

  • Контракты API (Swagger/OpenAPI): Описание того, как общаться с сервером.

  • Техническое Задание (Спецификация): Описание логики работы интерфейса.

Процесс работы

Часто фронтенд стартует:

  • либо чуть позже, когда у бэкенда уже есть договорённые адреса, по которым можно забирать данные;

  • либо параллельно, но тогда фронтендеры временно подставляют заглушки (моки) — фальшивые ответы, которые просто притворяются настоящими данными от сервера. Потом их заменяют на реальные.

Шаг 1: Анализ макетов и Декомпозиция на компоненты

Разработчик смотрит на макет и мысленно разбивает его на переиспользуемые блоки.

Пример: Страница каталога разбивается на компоненты: Header (верхушка сайта), ProductCard (карточка товара), FiltersSidebar (боковое меню с фильтром), Pagination (пагинация — нумерация страниц).

Это позволяет писать чистый, модульный код (например, на React, Vue или Angular).

Шаг 2: Верстка

Создание статической структуры и стилей. Например, с помощью базовых HTML и CSS

  • HTML (HyperText Markup Language): Создание “скелета” страницы (заголовки, кнопки, поля ввода).

  • CSS (Cascading Style Sheets): Наложение “кожи”. Применение цветов, шрифтов, отступов, теней в точном соответствии с макетами.

Шаг 3: Реализация Логики и Интерактивности

Оживление интерфейса.

  • Обработка событий: “При клике на кнопку ‘Купить’ → показать спиннер загрузки → отправить запрос на сервер”.

  • Валидация форм: Проверка данных, введенных пользователем, прямо в браузере (до отправки на сервер) для мгновенной обратной связи (например, “Некорректный email”).

Шаг 4: Интеграция с API

Связывание интерфейса с сервером.

  • Написание функций для отправки HTTP-запросов (GET, POST, PUT, DELETE) к бэкенду согласно контракту API.

  • Обработка ответов:

    • Успех (200 OK): Получение данных (список товаров) и их отрисовка на экране.

    • Ошибка (4xx, 5xx): Перехват ошибки и отображение понятного пользователю сообщения (“Сервер недоступен, попробуйте позже”).

Шаг 5: Управление Состоянием

Для сложных приложений используется специальный слой для хранения данных (например, Redux, MobX, Vuex).

  • Пример: Когда пользователь добавляет товар в корзину, это состояние должно обновиться глобально, чтобы счетчик товаров в шапке сайта сразу изменился, даже если пользователь находится на другой странице.

Шаг 6: Локальное тестирование и Самопроверка

Разработчик проверяет свою работу.

  • Визуальная проверка: Сравнение результата в браузере с макетом в Figma.

  • Функциональная проверка: Прокликивание основных сценариев.

  • Проверка адаптивности: Использование инструментов разработчика в браузере для имитации разных экранов (iPhone, iPad).

Ключевые Артефакты этапа

На выходе работы фронтенд-разработчика мы получаем:

  1. Исходный код (Source Code): JavaScript/TypeScript, HTML, CSS файлы.

  2. Собранный билд (Build): Оптимизированный, минимизированный набор файлов (JS, CSS, картинки), готовый к загрузке в браузер пользователя.

  3. Новые компоненты: Если были созданы новые переиспользуемые элементы, они добавляются в общую библиотеку компонентов проекта.

  4. Unit-тесты: Автоматические тесты для проверки логики компонентов и их внешнего вида.

Взаимодействие с другими ролями

  • С Дизайнером: Фронтендер задает вопросы, если в макете что-то непонятно или технически сложно реализуемо (“А как этот блок должен вести себя на очень узком экране?”). Демонстрирует результат для Design Review.

  • С Бэкендом: Договаривается о формате данных. Если API не работает как надо или возвращает не те данные, фронтендер сообщает об этом бэкендеру.

  • С QA: Объясняет, как протестировать сложные клиентские сценарии (например, поведение при потере соединения с интернетом).

Если бэк не готов

Чуть ранее в статье это было упомянуто, но важно еще раз это повторить.
При наличии доработок на бэке согласованный контракт API является блокирующим фактором перед взятием задачи в разработку на фронте.

Контракт API

Это формальный документ или спецификация (например, в формате Swagger/OpenAPI), который детально описывает все правила обмена данными между фронтендом и бэкендом до того, как код написан.

Контракт определяет:

  1. Эндпоинты (Endpoints): Адреса (URL), по которым фронтенд будет обращаться (например, /api/v1/users).

  2. HTTP-методы: Действие для каждого эндпоинта (например, GET для получения данных, POST для создания).

  3. Структуры данных: Точный формат (JSON) запросов (что фронтенд отправляет) и ответов (что бэкенд возвращает).

  4. Коды ошибок: Что бэкенд вернет в случае ошибки (например, 404 — не найдено, 401 — не авторизован).

Возможности обхода

  • Параллельная разработка: Имея на руках только контракт, фронтенд и бэкенд могут разрабатываться параллельно и независимо

  • Mock-сервер (Мок-сервер / Заглушка): Чтобы не ждать готовый бэкенд, фронтенд-разработчик использует “сервер-заглушку”. Это временный, “фальшивый” сервер, который настраивается так, чтобы на запросы по контракту API он отвечал статичными (заранее заготовленными) JSON-данными. Это позволяет разрабатывать и тестировать UI с данными, идентичными реальным.

JSON

JSON (произносится как «джейсон»), аббревиатура от JavaScript Object Notation — это текстовый формат обмена данными.

Фронтенд и бэкенд должны как-то договариваться, в каком виде передавать данные.

JSON — это общий язык для них: бэкенд отправил JSON → фронтенд его прочитал и показал на экране

➡️ Подробнее

Заключение

Что дальше?

➡️ Разберём Код ревью как процесс первой проверки

НазадДалее