Бэкенд-разработка — это процесс создания серверной части программного продукта (“движка”), которая отвечает за бизнес-логику, обработку данных, взаимодействие с базами данных и интеграцию с внешними системами.

Если Фронтенд — это то, что пользователь видит и нажимает, то Бэкенд — это скрытая часть айсберга, которая заставляет все это работать. На этапе Delivery бэкенд-разработчики превращают технические спецификации и контракты API в работающий, надежный и безопасный код.

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

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

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

  1. Реализация бизнес-логики: Написание кода, который выполняет правила бизнеса (расчет цены, проверка прав доступа, обработка заказа).

  2. Управление данными: Обеспечение надежного сохранения, чтения и обновления информации в базах данных.

  3. Обеспечение производительности: Оптимизация кода, чтобы сервер отвечал быстро даже при высокой нагрузке.

  4. Безопасность: Защита данных от утечек и взлома.

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

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

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

  • Контракты API: Согласованные форматы запросов и ответов.

  • Схема Базы Данных (ER-Diagram): Структура таблиц и связей.

  • Архитектурный Вижн Решения: Понимание того, какие микросервисы и технологии использовать.

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

Бэкенд-разработка обычно следует итеративному циклу внутри спринта.

Шаг 1: Настройка окружения и базы данных

Прежде чем писать логику, разработчик готовит «почву».

  • Миграции БД. Написание скриптов, которые создают новые таблицы или изменяют существующие в базе данных. Это гарантирует, что структура данных будет одинаковой во всех пространствах (у разработчика, на тесте, на проде).

Если совсем просто

Есть БД — большая аккуратная таблица (или много таблиц),
где программа хранит нужную ей информацию: товары, пользователей, адреса и т.д.

И чтобы эти базы везде выглядели одинаково, разработчик запускает файл с командами «как изменить структуру таблиц» во всех пространствах — это и есть миграция БД.

  • Генерация кода. Создание базового «каркаса» — моделей данных и контроллеров — на основе требований: либо вручную, либо с использованием инструментов кодогенерации.

Простыми словами

Есть сущности — это объекты из реального мира в коде (пользователь, заказ, товар).
Есть классы — шаблоны этих объектов. Например, пользователь User всегда идёт с полями id, name, email.

Описание того, какие поля есть у сущности и как это всё хранится/передаётся, называется модель данных.

Прежде чем разработчик приступит к логике, он создаёт черновой каркас кода: классы и заготовки обработчиков запросов. Это можно делать руками, а можно — с помощью специальных инструментов (кодогенераторов), которые строят этот каркас автоматически.

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

Шаг 2: Реализация API

Разработчик создаёт «двери», через которые фронтенд будет стучаться к бэкенду.

API (Application Programming Interface)

API (Application Programming Interface) — это интерфейс прикладного программирования, который позволяет одним приложениям взаимодействовать с другими.

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

➡️ Подробнее

  • Настройка ручек (Endpoint) и контроллеров (Controller) — адресов, по которым фронтенд обращается к бэкенду, и кода, который эти обращения обслуживает.

Ручка и Эндпоинт

«Ручка» (сленг), она же Эндпоинт (Endpoint) это конкретный адрес на сервере, по которому можно выполнить одно определённое действие.

  • Пример: Чтобы создать нового пользователя, фронтенд стучится в ручку: POST /api/users.
  • Пример: Чтобы получить список товаров, фронтенд стучится в ручку: GET /api/products.

Зачем это PM’у: когда вы планируете задачи, вы часто оперируете именно ручками. Вы говорите: «Нам нужна ручка для загрузки аватарки». Это минимальная единица функциональности API.

  • Реализация валидации входных данных (проверка, что email — это email, а сумма — положительное число). Если данные неверны, бэкенд сразу возвращает ошибку (например, 400 Bad Request).

Шаг 3: Реализация бизнес-логики

Это «сердце» бэкенда. Здесь пишется код, который не зависит от того, пришёл запрос с сайта или из мобильного приложения.
Пример: логика расчёта скидки, формирования заказа, отправки уведомления.

Реализация бизнес-логики обычно происходит при соблюдении особых принципов (например DRY (Don’t Repeat Yourself) и SOLID) для чистоты и поддерживаемости кода.

Шаг 4: Работа с данными

Написание запросов к базе данных или внешним API.

  • Использование либо готовых инструментов для общения с базой данных (ORM), либо написанных вручную специальных команд (SQL-запросы), чтобы сохранять и получать данные.

  • Оптимизация запросов для скорости работы.

Шаг 5: Написание unit-тестов (модульное тестирование)

Бэкенд-разработчик пишет код, который проверяет его же код.

Тесты проверяют отдельные функции в изоляции (например: «Функция расчёта налога возвращает 20% от суммы»).

Это гарантирует, что логика работает верно, и защищает от поломок в будущем.

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

Разработчик запускает код у себя на компьютере и проверяет его работу (например, через Postman или cURL), имитируя запросы от фронтенда.

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

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

  1. Исходный код (Source Code): закоммиченный в репозиторий (Git) и готовый к сборке.
  2. Миграции БД: файлы для обновления структуры базы данных.
  3. Unit-тесты: набор автоматических тестов, покрывающих бизнес-логику.
  4. Обновлённая документация API: если в процессе разработки контракт пришлось немного изменить (по согласованию с командой).

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

  • С Фронтендом: Бэкенд предоставляет API. Если фронтендеру не хватает какого-то поля в ответе, они обсуждают это и бэкендер дорабатывает API.

  • С QA (Тестировщиками): Бэкендер объясняет, как протестировать сложные сценарии (например, “как симулировать ошибку платежного шлюза”), и помогает анализировать логи при нахождении багов.

  • С DevOps: Согласует требования к инфраструктуре (нужна ли новая очередь сообщений, сколько памяти выделить сервису).

Заключение

Что дальше?

➡️ Погрузимся во Фронтенд разработку

НазадДалее