Советы молодым тим-лидам: как предотвращать простои фронтенда из-за задержек разработки бэкэнда

#Уголок_профессора

В современном мире разработки ПО часто возникает ситуация, когда frontend-команда движется быстрее, чем backend. Интерфейс готов, кнопки кликаются, формы заполняются, но... данные не поступают, потому что API ещё не реализован. Это приводит к простоям, задержкам и, как следствие, дополнительным издержкам в проекте.

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

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

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

Именно поэтому мы всегда это фиксируем в контрактах при помощи Swagger или OpenAPI. Например:

С таким документом фронтенд может начинать разработку, даже если бэкэнд ещё не начал реализацию.

Когда разработка бэкэнда отстает, мы используем мок-объекты. Это временная подмена реального API, которая позволяет фронтенду работать с заранее заданными структурами данных. Например, мы создаём сервер с помощью JSON Server:

1. Установка:

Этот простой инструмент позволяет фронтенду продолжать развиваться, не теряя темпа.

Для более сложных сценариев мы используем Express.js. Это позволяет добавлять логику, которая ближе к реальному поведению сервера, например, эмулировать ошибки, задержки или проверку прав доступа:

Чтобы фронтенд «не заметил», что данные поступают с временного сервера, а не с реального, мы настраиваем прокси. Это своего рода посредник, который перенаправляет запросы.

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

Однако, несмотря на преимущества, подход с использованием мок-объектов имеет и свои недостатки:

• сложности синхронизации — если контракт изменится, мок-объекты потребуется обновить;
• ограниченная функциональность — применение мок-объектов не позволяет полностью смоделировать реальное поведение сервера (например, возникновение ошибок или задержек);
• риски интеграции — финальные тесты с реальным API могут выявить неожиданные проблемы.

Чтобы минимизировать риски, рекомендуем:

• регулярно синхронизировать контракты между командами разработки;
• использовать инструменты автоматизации, например, Postman или MSW (Mock Service Worker) для упрощения работы с мок-объектами.

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

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