Большинство приложений обычно разделены на отдельные части: фронтенд и бэкенд. Фронтенд отвечает за то, что видит пользователь, в то время как бэкенд обрабатывает всю логику и вычисления. Это естественное разделение ответственности, которое используют большинство платформ просто потому, что это хорошо работает.
Однако при внесении изменений в приложение часто приходится менять и фронтенд, и бэкенд. Именно здесь нужны полнофункциональные инженеры, владеющие разработкой как на фронтенде, так и на бэкенде.
Работа и с фронтендом, и с бэкендом может быть сложной по нескольким причинам:
- Они часто написаны на разных языках: фронтенд на TypeScript, а бэкенд на Python.
- Приходится иметь дело с правами доступа и аутентификацией, а также сталкиваться с такими проблемами, как ошибки CORS.
- Фронтенд и бэкенд находятся в разных репозиториях и развертываются отдельно.
В этой статье освещаются основные моменты. Речь пойдет о том, как можно быть эффективным полнофункциональным инженером с помощью агентов программирования, и о конкретных методах, используемых мной ежедневно.
С появлением агентов программирования работать одновременно и с фронтенд-, и с бэкенд-кодом стало проще. Я дам вам общее представление о том, как ежедневно работать с кодом как на фронтенде, так и на бэкенде, и как обеспечивать бесшовную интеграцию двух систем.
Зачем работать одновременно с фронтендом и бэкендом
Причина, по которой нужно работать с кодом и фронтенда, и бэкенда одновременно, кроется в самой специфике веб-разработки. Допустим, вы хотите добавить новую функцию в свое приложение, где пользователь может сохранять свои разговоры с чат-ботом на основе ИИ и получать к ним доступ позже.
Эта функция требует изменений как во фронтенде, так и в бэкенде. Нужно обновить фронтенд для отображения предыдущих диалогов, и нужен бэкенд для обработки хранения и извлечения этих диалогов. Таким образом, у вас нет выбора, кроме как работать и с тем, и с другим кодом.
Более того, эффективность инженера, работающего и с фронтендом, и с бэкендом, значительно возрастает. Представьте, что вам нужно реализовать функцию сохранения диалогов чат-бота на основе ИИ, но вы работаете только над фронтендом. Вам пришлось бы реализовать свою часть, а затем согласовывать с другим бэкенд-инженером, как хранить диалоги. Понадобится выяснить:
- Какая будет схема хранения диалогов?
- Какие данные должны быть включены?
- Как следует назвать конечную точку?
Это слишком затратно. Если вы когда-либо работали в профессиональной среде разработки ПО, то знаете, сколько времени это занимает. Если же делать всю работу самостоятельно, не потребуется ничего согласовывать и можно справиться намного быстрее.
Методы продуктивной работы с кодом фронтенда и бэкенда
Теперь поговорим о методах, позволяющих продуктивно работать с кодом фронтенда и бэкенда. С появлением суперэффективных агентов программирования эта задача значительно упростилась: теперь для высокой продуктивности не обязательно быть экспертом с большим стажем работы в обоих стеках.
Использование Workspaces (рабочих пространств)
Workspaces — невероятно мощная функция при работе с несколькими репозиториями. В Cursor для этого используется функция «Add workspace». В случае с CLI-инструментами достаточно просто указать агенту путь к нужным репозиториям. Теперь модель будет иметь контекст обоих соответствующих репозиториев и сможет реализовать полнофункциональное решение за один раз.
Workspaces — замечательный метод. До того, как я его открыл, приходилось работать с двумя отдельными вкладками Cursor: одна с кодом фронтенда, другая с кодом бэкенда. Я вносил изменения во фронтенд и вручную обновлял бэкенд, чтобы он принимал эти новые изменения.
Неудивительно, что на выпуск новых функций у меня уходила уйма времени. Теперь я просто даю агенту команду обновить фронтенд согласно инструкциям, и он автоматически обновляет бэкенд соответствующим кодом, чтобы принять изменения во фронтенде. Конечно, это работает и в обратную сторону.
Монорепозитории
Монорепозитории также очень эффективны. Альтернативой монорепозиторию является распределение всего кода по разным репозиториям (обычно называемым микросервисами). Знаю по собственному опыту, что это работает не очень хорошо, поскольку усложняет вам и агентам программирования процесс отслеживания того, где что находится.
Настоятельно рекомендую перенести все в монорепозиторий, где весь код находится в одной кодовой базе. Это позволит легко создавать правила, такие как pre-commit-хуки, которые применяются ко всему коду, и вам не нужно дублировать их в нескольких репозиториях. Кроме того, вы сможете легко создать файлы AGENTS.md, охватывающие и объясняющие весь репозиторий, чтобы агенты могли легко отслеживать расположение каждого компонента.
Если весь код перенести в монорепозитории, скорее всего, не понадобятся рабочие пространства (workspaces), описанные в предыдущем разделе. Однако часто бывает, что для кода фронтенда/API используется монорепозиторий, а отдельный репозиторий обрабатывает более сложные процессы, такие как запуск агентов или обработка документов. Таким образом, вам все равно придется использовать рабочие пространства.
AGENTS.md как контекст
Еще один важный совет — активно используйте и обновляйте AGENTS.md. Существует множество альтернатив AGENTS.MD, таких как CLAUDE.md, WARP.md или .cursorrules. Однако в процессе работы я убедился, что AGENTS.MD читается всеми агентами программирования, независимо от того, какой из них вы используете.
Поэтому рекомендую остановиться на AGENTS.md. Этот формат универсален, так что при любом раскладе — смене агента или работе в команде, использующей другие агенты, — вы ничего не потеряете.
Можете поместить файл AGENTS.md в корневой каталог своего репозитория, который будет давать общее представление о репозитории, что-то вроде README. Это позволит агенту легко понять, какие папки содержат какую логику, и облегчит ему навигацию по коду.
Можно также разместить AGENT.md во всех подпапках. Например, если у вас есть сервис в одной папке, поместите туда файл AGENTS.md, объясняющий, как работает этот сервис, или какие-либо особенности, о которых следует знать.
Важно только обязательно обновлять AGENTS.md при каждом внесении изменений в код. Можно, например, поручить агенту программирования обновить соответствующие файлы AGENTS.md с учетом того, что он узнал за последнюю сессию, и он автоматически добавит важные заметки. Не забудьте также отправить эти изменения в GitHub, чтобы ваши коллеги могли воспользоваться полученными вами знаниями.
Заключение
Итак, мы разобрали, как эффективно работать с кодом на обоих стеках: зачем это нужно и какие инструменты (рабочие пространства, монорепозитории и AGENTS.md) помогают в повседневной практике.
Убежден, что будущее — за полнофункциональными инженерами. Агенты программирования стали настолько эффективны, что наша роль трансформируется: мы перестанем писать все подряд и можем сосредоточиться на координации, выбирая самые важные задачи и лучшие пути их решения.
Читайте также:
- Laravel 12 AI SDK: создание SaaS-приложений со встроенным ИИ
- Секреты бэкенд-разработки на Node.js, которые никто не раскрывает
- Angular-приложение, которому потребовалось на два фронтенд-инженера меньше
Читайте нас в Telegram, VK и Дзен
Перевод статьи Eivind Kjosbakken: How to Work Effectively with Frontend and Backend Code
