Что должен уметь фулстек-разработчик

Фулстек-разработчик умеет работать и с клиентской, и с серверной частью приложения. Звучит удобно: один человек может сделать задачу целиком. Тогда почему команды не состоят из одних фулстеков? И что именно должно стоять за этим названием, кроме длинного списка технологий в резюме?

Об этом я поговорил с Алексеем Малейковым, техническим директором HTML Academy. Лёша начинал с вёрстки, JavaScript и PHP, работал с обеими сторонами приложения, а к моменту нашего разговора уже руководил разработкой. Я расспросил его о том, где такой опыт помогает и обязательно ли фронтендеру двигаться в эту сторону.

Задача, которая проходит через всё приложение

Я попросил Лёшу начать с задач. Перечислить языки и библиотеки несложно, но из перечня ещё непонятно, какую работу можно поручить человеку.

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

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

Язык на сервере не определяет эту роль. Это может быть PHP, JavaScript, Python или что-то ещё. При найме важны инструменты компании: опыт с Node.js ещё не означает, что человек сразу разберётся в серверном коде на другом языке.

Лёша привёл пример прямо из нашего эфира — чат, в который зрители отправляли вопросы. Его команда сделала клиент на обычном JavaScript, а сервер — на Node.js, с Socket.IO для обмена сообщениями. Небольшое приложение, в котором есть работа и на клиенте, и на сервере.

Почему одного человека не всегда достаточно

Если фулстек делает задачу целиком, зачем тогда нужны отдельные специалисты по фронтенду и бэкенду?

Лёша начал с того, что в обеих областях много знаний, и они постоянно обновляются. Удерживать одинаковую глубину сразу в двух направлениях трудно. Разработчик, который сосредоточен на одном из них, может лучше разобраться в сложной задаче именно в своей области.

Есть и время. Фулстек не становится двумя людьми: пока он пишет серверную часть, клиентская ждёт, и наоборот. Два специалиста могут работать параллельно. Поэтому меньшая команда не всегда закончит работу быстрее.

Зато одному человеку проще согласовать устройство API с интерфейсом. Не нужно сначала объяснять задачу одному разработчику, затем другому, а потом обсуждать, почему ответ сервера не подходит для экрана. Фулстек видит обе стороны и может сразу выбрать решение, с которым ему будет удобно работать.

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

Самостоятельность и второе мнение

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

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

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

Я возразил, что общение и обмен опытом нужны любой команде. Несколько фулстеков тоже могут обсуждать задачи и смотреть код друг друга. Широкая специализация не означает, что человек должен работать в одиночестве.

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

Похожим образом мы разобрали опасение, что фулстек, который написал всё приложение, становится незаменимым. По мнению Лёши, проблема возникает не от самой роли. Если устройство проекта можно понять, подходы знакомы команде, а необходимое описано, другой разработчик сможет продолжить работу. Автор тоже забывает детали собственного кода: через год ему самому может понадобиться такое объяснение.

Что нужно знать за пределами языка

С Node.js легко решить, что знания JavaScript хватит и для сервера. Синтаксис знакомый, но обрабатывать запросы и хранить данные пока не приходилось.

Лёша перечислил несколько вещей, которые связывают клиент с сервером. Как устроен HTTP-запрос, что передаётся в заголовках и теле, как работает авторизация, когда нужен WebSocket. Нужно понимать не только вызов функции в библиотеке, но и то, что происходит между браузером и приложением.

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

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

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

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

Открыть серверную часть знакомого проекта

После такого перечня легко решить, что учиться придётся всему сразу. Я спросил Лёшу, не получится ли у начинающего вместо знаний смесь незнакомых терминов.

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

В Академии мы связывали обучение примерно таким образом. На курсе по фронтенду студент делал клиентское приложение, а сервер уже был готов. Было известно, по какому адресу обращаться, что отправить и какой ответ ожидать. Для задачи с интерфейсом этого достаточно, но устройство второй стороны пока остаётся закрытым.

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

Мне нравится, что так студент разбирается в сервере, с которым уже работал. Даже если он останется во фронтенде, ему будет проще обсуждать задачи с теми, кто делает бэкенд.

Не каждому нужно начинать с картинки

Лёша предположил, что начинать с фронтенда проще: написал немного HTML и сразу увидел результат. Для первого знакомства это действительно удобно. Но я не согласился с тем, что видимый результат одинаково важен всем.

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

Лёша уточнил, что говорил о коротком пути к первому результату, а не о простоте фронтенда вообще. Сложный интерфейс требует большого объёма знаний, как и сложная серверная система. Первая HTML-страница просто позволяет быстро увидеть связь между написанным кодом и тем, что получилось.

Фулстек внутри большой системы

Ещё один вопрос возник из самого слова «всё». Должен ли фулстек уметь написать любой бэкенд, с которым взаимодействует его интерфейс? В большой компании за экраном могут стоять несколько систем на разных языках, с очень разными требованиями к нагрузке и обработке данных.

Я привёл вариант с бэкендом для фронтенда — BFF. Основная серверная система отдаёт данные в виде, который не очень удобен конкретному интерфейсу. Между ними появляется отдельное приложение: оно обращается к нужным сервисам, собирает ответы и подготавливает их для клиента.

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

Направление и уровень — разные вещи

Я отдельно спросил, обязательно ли рост фронтенд-разработчика должен привести к фулстеку. Можно ли остаться во фронтенде, глубоко разбираться в нём и заниматься сложной архитектурой?

Лёша не считал фулстек обязательной ступенью. Можно расти внутри одной области. Знание соседней полезно для общения и принятия решений, но из этого не следует, что каждый должен постоянно писать обе части приложения.

Широкий опыт может помочь руководителю понимать работу разных разработчиков. Само умение писать фронтенд и бэкенд руководить людьми не научит.

Тогда возможен и джун-фулстек. Лёша объяснял это через самостоятельность: начинающий решает ограниченные задачи и нуждается в помощи, опытный справляется с более сложными и понимает последствия своих решений. У первого задачи тоже могут затрагивать обе стороны приложения.

Вопрос о найме такого человека я вернул к его команде. Если есть время и люди, которые помогут освоиться, Лёша готов брать начинающего разработчика. Тот учится подходам компании и постепенно берёт на себя больше. Если таких ресурсов нет, одна подходящая строка в резюме проблему не решает.