Привет! Сейчас я попробую кратко, но ёмко описать, кто такой фулстек-разработчик, и почему он ценен для бизнеса. Также, расскажу о плюсах и минусах фулстека перед схемой, когда есть отдельно фронт и бэк разработка.
Маленькая ремарка. Я сначала вам дам информации к размышлению, затем вгоню в ступор, а после подскажу один из множества вариантов того, каким путём можно двинуться к намеченной цели. Плюс в конце будет мощное объявление о приятном бонусе. Так что смотрим до конца.
Традиционно в вебе сложилось так, что фронтенд писался на Javascript — так есть и сейчас, но только со временем фронтенд оборос колоссальным количеством различных фреймворков, библиотек, концепций, подходов, методологий и прочего такого. В корне же всё тот же (хотя и очень повзрослевший) JS, правда страдающий от наследственных пороков вроде прототипного наследования или очень странных результатов проверок и сравнений типов. Соответственно, раз сфера достаточно сложная и работа ограничена браузерами на стороне клиента, то логично чтобы этим занимались отдельные спецы. Так фронтенд постепенно и выделился в отдельную профессию.
Бэкенд же, в свою очередь, можно сказать был задолго до явно оформившегося фронтенда. Ведь фронт по началу, примерно до появления web 2.0 в районе 2005 года, играл очень небольшую, чуть ли не украшательную роль, а всё самое основное делалось на серверах.
И сейчас многие проекты используют древний, но проверенный подход, когда основная часть работы делается на бэкенде и браузер пользователя получает лишь готовый HTML/CSS/JS, где JS делает какую-то относительно небольшую работу — инициализирует слайдеры, гамбургеры, аккордеоны, табы, виджеты аналитики, сторонних сервисов техподдержки и прочее такое, что мало соотносится с бизнес-логикой продукта.
Но всё движется к SPA — Single Page Application (одностраничное приложение, не путать с лендингом-одностраничником), где подход принципиально иной — с сервером мы обмениваемся чистыми данными в формате JSON, а приложение инициализируется буквально с пустого HTML-документа к которому подгружается бандл с JS-кодом, где описываются различные страницы нашего приложения, то как они взаимосвязаны, как на них, в зависимости от состояния данных показываются те или иные элементы пользовательского интерфейса, и так далее.
В итоге, c появлением и развитием SPA-подхода, профессия фронтендера очень усложнилась и окончательно стала прям отдельной сферой. Я не раз уже от бэкендеров слышал, мол как вы там вообще на фронте живете — это же ужас как замороченно и сложно..! Ну как сказать, привыкаешь… ведь на бэке своих заморочек хватает.
Бэкенд, как и фронтенд это отдельные друг от друга миры. Как их состыковать? Как бесшовно организовать работу группы специалистов над одним или несколькими проектами? Хороший вопрос. В глобальном смысле на него пытается ответить «наука» управления проектами. Наука конечно сказано, но там действительно очень много наработанных годами теорий и технологий. Однако мы рассмотрим вопрос с более конкретной, технарской стороны, не погружаясь глубоко в менеджерские вопросы.
Обычно (чаще всего) задача не ставится заказчиком или менеджером четко и напрямую, в виде ТЗ, мол вот нужно такое, таким образом, так должно выглядеть, так работать. Более того, очень часто задача поступает скомканно и неточно, что приходится исправлять обсуждениями и написанием документов.
Но кроме уточнений, надо понять, что сделать на бэке, а что на фронте, чтобы всё заработало. Это задача общения технарей, которые должны понять поставленное с точки зрения технологической внутрянки и разделить выполнение между собой. Задачи на спринт (условно это промежуток времени длиной в неделю или две) обычно приходят в общем виде и тогда их нужно декомпозировать, то есть делить на более мелкие подзадачи. И по появившимся задачам тоже нужно будет понять где чья зона ответственности и назначить на конкретного исполнителя или исполнителей + назначить ответственного. По итогу обсуждений, в таск-трекере (софте, где фиксируются задачи, их исполнители, сроки, статусы и другая информация) появлятся деление на фронтовые задачи и задачи для бэкенда.
Следующим этапом будет оценка времени на выполнение и в какой спринт та или иная задач пойдёт. Но задачи бывают разными по объёму, приоритету и характеру. Проще всего с багами (где-то что-то не работает или падает/зависает). Их как правило легче всего отнести целиком к фронту или бэку. А вот когда приходят задания на создание нового функционала, тут нужно не просто разнести задачу по имеющимся специалистам, а ещё и учесть, что одни этапы работ могут блокировать другие, что определенные важные задачи для бэкенда, могут забрать много времени в спринте и не дать возможность исполнить то, что неоходимо для движения вперед по фронту. Так, задачи имеют свойтво сдвигаться из одного спринта в другой, что не может радовать так как работа обычно всегда планируется и заказчик или его представитель уведомляется о том, что в такое-то время будет готов тот или иной функционал.
Я думаю вы поняли основную мысль, что задачи делятся между специалистами двух разных областей — фронт и бэк. И количество доступных фронтов/бэков и количество доступного у них времени может влиять, учитывая возможность наличия блокирующих задач, на задержки в процессе разработки. Если вдруг в команде не хватает спецов того или иного профиля, то неизбежно будут перекосы, задержки и переносы.
Более того, на согласование границы водораздела между фронтом/бэком само по себе требуется больше времени, чем если один человек вникнет в задачу и сделает её сам. По крайней мере, из моего опыта это так. Тут есть много «если», конечно, но в целом примерно так и обстоят дела.
Если чуть детальнее посмотреть на техническую сторону дела, то для большинства задач нам нужно API — набор адресов, откуда мы можем получать данные и куда их можем записывать, чтобы всё работало. Я намеренно упрощаю. Так вот, для упрощения дела, фронт и бэк договариваются куда, что и в какой форме они будут друг другу отправлять и пишут свой код так, будто это уже работает, но сами сетевые запросы мокают, то есть подставляют статические имитирующие реальный процесс болванки-данные (это больше фронта касается).
Таким образом, можно одновременно писать и тесты и код, реализующий логику работы приложения. Так, в общем-то и выходят из ситуации обычно. А вот когда соединяют паззлы и подключают фронт к бэку, там уже доделывают то, что не смогли предусмотреть заранее, тестируют и выкатывают, что называется, в продакшен, где юзеры смогут этим всем написанным воспользоваться.
Это наиклассическая схема в большинстве проектов, особенно в крупных компаниях.
Но есть и альтернатива. Я специально назвал ролик «Как стать Fullstack JAVASCRIPT разработчиком», потому что считаю, а поспорить с этим сложно, что именно вариант, когда и фронт и бэк написаны на JS, наиболее прост в конексте фулстек-подхода к разработке. Часто встречаются вакансии PHP + JS или Python + JS, но эти пары сложнее для освоения, ведь языки разные. Многие приходят в фулстек как раз с фронта и тогда логично выбрать NodeJS, правда ведь?
Есть люди, которые считают что на ноде нельзя писать сложные приложения. Да, может банковские системы так делать и не будут, но многие другие проекты прекрасно на таком стеке пишутся. NodeJS давно уже является профессиональной средой с огромным количеством пакетов для решения множества задач. Если интересно, то почитайте холивары на разных форумах или посмотрите ролик на эту тему, но разговоры разговорами, а проекты пилятся и работают. Или пилятся, а потом не работают. По-разному бывает.
Итак, при фулстек-подходе, кадждый специалист должен знать и бэк и фронт. Но это общие слова. Знать можно в разном объёме. Обычно речь идет про конкретные фреймворки, библиотеки, пакеты. И частенько на проекте есть лид-разработчик, который, если что, подскажет решение сложных моментов и скоординирует работу с другими специалистами в команде.
Как, в сравнении с подходом, когда спецов делят на фронтов и бэков, выглядит фулстек-подход?
Задачи всё так же поступают, скорее всего, в общем виде, а нередко разработчикам приходится быть и бизнес-аналитиками. Но теперь ситуация такова, что задача даётся без деления её на фронтовую и бэковую часть. Логично, что в таком случае, даже один специалист может двигать проект вперёд и его ничего не будет блокировать. Нет, конечно блоки могут прийти со стороны заказчика, который может быть в раздумии, какой путь решения для бизнес-процесса выбрать или со стороны дизайнера, который нам макет не отрисовал, но не будет ситуации, когда фронт не может двинуться дальше, потому что для нет соответствующего бэка.
Если преставить весь объём задач как параллелипипед, разделенный на две части, то при подходе «бэк-фронт» специалисты работают только в своей нижней или верхней части объёма, условно горизонтально. А вот при фулстек-подходе все работают и горизонтально и вертикально, во всём объёме задач.
Нанял два фулстека и работа пошла в два раза быстрее. Если конечно нет провала по планированию, анализу и другим аспектам.
Блокировки, надо сказать, могут быть и тут, если мы на спринт даём задачи двум фулстекам, одна из которых зависит от другой. Но это относится к вышеперечисленным аспектам, по которым могут быть провалы.
Тема того, кого лучше нанимать — фулстеков или обычных — крайне дискуссионная. Всё зависит от слишком большого количества факторов, чтобы так просто отвечать на этот вопрос. Я скорее ЗА такой подход, нежели против, потому что мой опыт тут позитивный.
Часто говорят, что фулстек по определению не может быть хорошим спецом, потому что он хватает всё по верхам. И да, и нет. Правильно будет задать уточняющий вопрос — сколько лет он в разработке? 1, 2, 5, 10? Насколько плотно он занимался всё это время своей специальностью? Что конкретно делал? Была его работа повторяющимся ремеслом или была насыщена сложными задачами, требующими поиска нестандартных решений?
Но самое главное — его набор знаний и умений подходит под задачи конкретного проекта? Если да, то может он работодателя устроит? Почему бы и нет, если задачи будут решаться и прогресс налицо.
Короче говоря, говорить на эту тему можно бесконечно, но я бы рекомендовал вам не теоретизировать, а прокачиваться, работать с кодом и приобретать опыт прямо сейчас — это важнее всякой философии. Вот как раз когда ты накопил практического опыта, он автоматом начинает обощаться и выливается в более общие мысли. Это неизбежно происходит по мере взросления человека как специалиста, да и как личности тоже.
В принципе, Javascript-фулстек это все равно, что если бы вы совместили требования к вакансии фронтендера и бэкендера на NodeJS. Сейчас я попробую огласить приблизительный общий список того, что требуется от Javascript-фулстека с вилкой вариантов.
Начнем с требований фронта:
— Знание HTML/CSS (ведь какой ты фронт, если не умеешь верстать)
— Адаптивная/кроссбраузерная верстка
— Знание нативного JS (от ES2015 и далее)
— Sass/Less (реже), CSS-in-JS (всё чаще встречается)
— jQuery редко, но встречается, но лучше туда не соваться ИМХО.
— React / Vue / Angular в качестве базы для фронта.
— Стейт-менеджер (актуально больше актуально для React) чаще всего redux (нередко redux toolkit), реже mobx или нативный реактовский useContext.
Теперь про требования к бэку:
— Знание NodeJS, работа с файловой системой.
— Навыки построения API
— Навыки построения запросов к базе (чаще всего через ORM, но бывает и чистые запросы писать надо)
— Знание фреймворков типа express.js, koa.js, nestjs или других.
— Умение работать с базами данные — SQL-ными типа Postgres и MySQL, либо NoSQL вроде MongoDB (это наверное 95 процентов всех вакансий).
— Работа с npm/yarn для подтягивания зависимостей.
— Работа с axios для выполнения сетевых запросов с бэка — актуально при микросервисном подходе и когда есть внешние API для получения данных нужных в работе продукта.
— Работа с шаблонизаторами для подстановки данных в HTML-шаблоны, которые отправляются клиенту
— Организация отлова ошибок и их логирования, автоматизированные инструменты для оперативного уведомления об ошибках в виде сообщений СМС, Телеграм, на почту.
— Оптимальное проектирования базы данных под задачи проекта, чтобы всё выполнялось за приемлемое время.
— docker для обертывания приложения в изолированные контейнеры
— организация CI/CD для автоматизированного билда приложения и его развертывания на сервера — а-ля сделал коммит и всё обновилось, вместо нудного ручного процесса через консоль.
А теперь то, что относится и к бэку и к фронту:
— Работа с командной строкой, распространенными консольными программами и Linux’ом.
— Умение работать с Git
— Понимание RestAPI и особенностей обмена информаций между сервером и клиентом, реже используют GraphQL.
— Основные алгоритмы и паттерны проектирования (есть базовые-классические, а углубляться можно до бескончности).
— Знание Typescript (ведь на сегодня это индустриальный стандарт)
— Понимание идей объектно-ориентированного программирования
— Умение принимать более-менее грамотные архитектурные решения, которые учтут развитие проекта в будущем.
— Навыки рефакторинга, чтобы мочь погрузиться в чужой г.. код.
— Авторизация через JWT-токены
— Умение писать как минимум юнит-тесты (не везде требуют, но вещь полезная).
— Работа в таск-трекерах и по Scrum-методологии (это вообще самый простой пункт)
— Знание английского для чтения доков и stackoverflow
То, что в зависимости от проекта могут просить:
— Canvas (для шустрой работы с графикой)
— WebGL, для 3D
— WebSocket — для чатиков и прочей реалтаймовой штуки.
— Video/audio — обучающие платформы, чатики, соц.сети, стриминговые платформы и т.д.
— Умение переводить приложение на разные языки (мультиязычность)
— Диспетчеры очередей типа RabbitMQ или аналогов, чтобы иметь возможность откладывать запросы и выполнять их по мере высвобождения ресурсов.
— Организация гибкого поиска по базе данных (например, elastic search)
— Опыт работы с Amazon WebServices.
Стоит упомянуть про то, что описанные преимущества Single Page Applications это конечно хорошо, но есть один минус — SPA изначально по своей природе, не умеют при первом запросе HTML-документа, выдавать разметку с заполненной информацией. А поисковики до сих пор этого не любят и неохотно выполняют JS-код, чтобы понять, как приложение будет выглядеть с данными после начального исполнения скриптового кода. По крайней мере, SEO-шники не практикуют такой подход и всё ещё требуют чтобы в HTML-ке сразу были данные.
Возможно это инерция, но кажется, что в данном направлении нам нужно ещё подождать и, для SPA, прикручивать так называемый, SSR (Server Side Rendering) — отрисовка на стороне сервера, когда который выполняет первоначальные запросы к базе данных и заполняет HTML-страничку контентом, чтобы поисковому роботу, который пришел на наш сайт или на одну его из подстраниц, можно было бы сразу же проиндексировать содержимое и оно бы, возможно, появилось бы в результатах поисковой выдачи Гугла или Яндекса.
Тут можно написать свой руконогописный вариант SSR или заиспользовать что-то вроде NextJS для React или NuxtJS для Vue, где этот механизм уже встроен «фкаропку». Так что на некоторых вакансиях также требуется знание и этих методик и технологий.
Если вас ещё не хватил инфаркт одновременно с инсультом от перечисленного зоопарка, то скажу что это некий список максимум. В зависимости от проекта и требований к вакансии, он точно уменьшится в объёме, так что пугайтесь, но не сильно.
Вообще, у меня у самого в какой-то момент стал отваливаться мозг, потому что я мог список потенциальных требований расширять чуть ли не до бесконечности — настолько много всего интересного есть в мире разработки.
Я вначале вам сказал неправду, на самом деле, ведь четкого ответа на вопрос о том, как стать фулстеком на JS — не существует. Хотя нет.. существует, но он вам не понравится — нужно учиться и трудиться годами и тогда, возможно, вы станете фулстек-разработчиком.
Но весь смех в том, что никакой четкой универсальной шкалы для оценки таких спецов не существует. Есть лишь некоторые примерные ориентиры, которые каждый трактует как хочет. Всё достаточно условно во вселенной веб-программирования. Есть джуны, миддлы и сеньоры-помидоры, но вот описания и требования к каждой категории лишь примерные. Хотя в целом определённые соглашения в индустрии имеются.
Такая вот история.
Вогнал вас в уныние? Не отчаивайтесь.
Вот та самая небольшая обещанная пилюля помощи.
Я запускаю свой авторский курс по обучению фулстек-разработчиков.
Он будет расчитан на тех, у кого уже есть базовый опыт веб-разработки. То есть, подразумевается, что вы уже может быть даже где-то работали разработчиком и имеете представление и опыт работы с HTML/CSS/JS, может вы делали сайты с помощью NodeJS или PHP и так далее, но вы не являетесь полноценным фулстек-разработчиком. А может вы просто самостоятельно изучали и практиковались. В этом случае, курс как для вас.
Он представляет собой заранее записанные уроки. Будет их достаточно много, на несколько месяцев плотной работы, а скорее всего больше. То, что записаны заранее, позволит вам не тратить время на паузы и тормоза в выступлении, всё будет заранее отмонтажировано. Можно поставить на паузу, ускорить, перемотать. А через время пересмотреть. К роликам будет прилагаться описание с временнЫми метками, для упрощения ориентирования и поиска нужной информации в дальнейшем.
В эти уроки войдут как теоретические вещи, так и процесс создания простейшего по функционалу приложения-маркетплейса с фронтенд-частью, админкой и кабинетом продавца. Это очень хороший кейс, который позволит понять очень многие вещи и затем создавать нечто подобное самостоятельно или в составе команды. Курс создаётся на основе реального опыта создания маркетплейса с нуля, поэтому опыт будет передаваться «боевой», а не «доморощенный».
Все видео будут публиковаться на ютубе в закрытом доступе, анонсы будут в телеграм-паблике, а для тех, кому неудобно — видео будут дублироваться на облачном диске. Для общения вы получите доступ в телеграм-чат, где кроме взаимопомощи участников, на вопросы будет отвечать автор курса. По мере накопления вопросов мы будем встречаться в онлайне с возможностью спрашивать голосом и видео. Там я буду отвечать на ваши вопросы, а запись затем пойдёт в паблик и будет доступна для просмотра.
До начала публикации первых записей, 5 сентября вы сможете получить скидку в 20% от стоимости курса. Так что пишите в указанный телеграм и забивайте своё место прямо сейчас.
В описании к ролику будет ссылка на телеграм, куда можно написать и узнать стоимость, условия и другую интересующую информацию.
Кроме того, существует возможность своего рода кэшбэка. Если вы сами купили курс и по вашей рекомендации придёт человек, который оплатит полную стоимость курса, то вам возвратится 30% от стоимости его оплаты! Это вообще праздник щедрости! Нигде таких кэшбеков нет)) Только у нас))) Чтобы зафикисировать рекомендацию, также пишите в телеграмм.
Все важные ссылки в описании к этому ролику! Пожалуйста, читайте все подписи и ссылки внимательно, чтобы не задавать лишних вопросов.
В заключении, хочу сказать, что веб-разработка это большой труд, но если вам эта сфера интересна, то просто продолжайте изо дня в день, изучать и практиковать. Мой личный опыт ковался, на данный момент, уже более 10 лет, не считая того, что я столкнулся с компьютерами ещё в возрасте 11 лет и уже тогда начал пытаться что-то программировать, заглядывать во внутренности различных софтовых и железных систем компьютера.
Если же четко выбрать направление и не распыляться, то на хорошие коммерческие рельсы можно встать довольно быстро, за пару лет. В любом случае, я желаю удачи на вашем пути.