Разработка
Work Solutions

Злые и дикие: какими бывают фулстек-разработчики и зачем они нужны

Может ли один программист создать современное приложение, и есть ли у такого подхода шансы в сравнении с командной разработкой? Если коротко, то ответ на оба вопроса — «да», но все не так просто. Подробнее читайте в материале.

Рассвет и закат фулстеков

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

Создание веб-сервисов нового поколения становилось непомерно дорогим. Это было напрямую связано с накладными расходами — так как подключалось все больше людей, затраты на коммуникацию увеличивались в геометрической прогрессии и замедляли разработку.

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

В вебе большую популярность набрал LAMP-стек с открытым исходным кодом всех компонентов (Linux, Apache, MySQL, PHP / Python / Perl) и проприетарный стек Microsoft (Windows Server, SQL Server, IIS, ASP.NET). Появились инструменты, которые ускорили разработку серверной части, а технологии jQuery/CSS3/HTML5 помогли с отрисовкой интерфейсов. Рост популярности был также связан с доступностью решений для хостинга.

Независимо от стека, конечным результатом веб-запроса был код HTML/CSS/JS, который приходил от сервера. HTML предоставлял контент, CSS делал его красивым, а JavaScript добавлял немного интерактивности. Сервер объединял HTML-шаблоны с бизнес-данными для создания отрисованной страницы в браузере.

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

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

По мере развития JavaScript-фреймворков появилась возможность создавать нагруженные интерфейсы в реальном времени в браузере. Стали появляться одностраничные приложения вроде Facebook и Google Maps. Фронтенд-разработка превратилась в отдельную специализацию.

Пришла пора прощаться с мыслью о том, что один человек сможет создать и запустить современный цифровой продукт… или нет?

Покойся с миром, фулстек. Да здравствует Т-образный специалист!

Мысль об универсальном специалисте слишком соблазнительна, чтобы просто так ее отпустить. Поэтому сегодня часто говорят о T-образных компетенциях. Придуманный американскими рекрутерами в 80-х годах термин обрел новую жизнь.

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

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

Например, для фронтенд-разработчика вертикальная черта отвечает за владение технологиями, понимание разных подходов к программированию, знание лучших практик. Горизонтальная черта — это про умение находить общий язык с дизайнерами, понимание UX/UI, а также, например, SEO. Такой специалист видит глобальную картину и принимает правильные решения.

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

Матрица компетенций программиста разрослась до небывалых размеров — охватить все одному человеку не под силу. Смирившись с таким положением дел, под фулстеком стали понимать специалиста, который сможет самостоятельно разрабатывать бэкенд и фронтенд на современных технологиях. Но требовать от программиста одинакового уровня знаний в этих сферах — все равно что требовать одинаково хорошо писать правой и левой рукой. Поэтому внутри технических навыков стали выделять T-форму.

Выбираем стек правильно

При создании ПО разнообразие выбора может привести в ступор. Что лучше подойдет: Python или PHP? React или Angular? Использовать проверенные инструменты или пробовать новые технологии? Эти вопросы задают себе как опытные, так и начинающие программисты.

Чтобы упростить бесконечное число вариантов, инженеры выбирают готовые стеки, которые служат руководством по выбору и интеграции компонентов веб-ресурса.

Стек часто определяет ОС, базу данных, веб-сервер и язык программирования. Чуть выше мы говорили про LAMP и Microsoft, но сегодня таких наборов инструментов стало значительно больше. Такие стеки помогают не мучаться с выбором, быстро приступить к работе и сосредоточиться на бизнес-задачах.

Большую популярность в профессиональном сообществе обрел MEAN-стек, который позволил создавать серверную и клиентскую часть на JavaScript, в состав которого входят:

  • MongoDB для хранения данных в виде документов в формате JSON.

  • Express.js — это бэкенд-фреймворк, работающая поверх Node.js.

  • Angular.js — это фреймворк для интерфейсных веб-приложений, запускающий JS-код в браузере пользователя.

  • Node.js — среда выполнения JavaScript, позволяющая вести серверную разработку на JavaScript.

Акроним MEAN можно также перевести с английского как «злой». В отличие от предшественников, в нем не указана операционная система, но впервые указана клиентская среда, которая играет столь важную роль, что с появлением React и Vue акроним трансформировался в MERN и MEVN.

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

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

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

Для проектов со сложной серверной логикой, но относительно простыми интерфейсами — корпорталы, системы личных кабинетов, решения для бэк офиса — следует рассмотреть другой набор инструментов, например, VILT, который включает:

  • Vue.js — простой в освоении JS-фреймворк, который предоставляет много готовых компонентов;

  • Inertia.js — библиотека, которая заменяет маршрутизатор Vue на маршрутизатор Laravel;

  • Laravel — самый популярный на сегодняшний день PHP-фреймворк;
  • Tailwind CSS — библиотека, упрощающая работу со стилями.

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

Стек придумали и распространяют PHP-программисты, которые оценили все достоинства современных JS-технологий и захотели полностью контролировать разработку приложений.

Закон Конвея или когда лучше выбирать разработку на MEAN или VILT-стеке

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

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

Мелвин Конвей
Ученый в области теории вычислительных машин и систем

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

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

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

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

Важно не гнаться за мифическим фулстеком. Лучше определить, какой из стеков вам подойдет. Сложная логика на бэкенде со стандартными интерфейсами? Выбирайте VILT. Одностраничное приложение со сложным интерфейсом, но простой серверной частью? Выбирайте ME(A/R/V)N-стек.

Спасибо, что дочитали до конца! Это блог IT-продакшна Work Solutions. Мы занимаемся аутсорсингом и аутстаффингом: создаем веб-приложения на заказ и усиливаем штат наемных специалистов. Будем очень рады вашим:

⭐ на GitHub;

➕ на Хабре;

❤ в VK.

0
55 комментариев
Написать комментарий...
Alex Archer

Мой опыт говорит о том, что фуллстек как специалист-клей всегда пригождается в командах узких разработчиков. Потому что узкие специалисты зачастую не смотрят на систему "с высоты", и возникают проблемы с ошибками на стыках технологий. Фулстеки помогают связывать воедино такой расползающийся проект. Если бы у меня был выбор, я бы предпочел команду фуллстеков. Другое дело что их на рынке меньше чем узких специалистов, отбирать HR их проще, управлять - сложнее. Поэтому бизнес предпочитает более простые и понятные варианты.

Ответить
Развернуть ветку
Gre Li

То, что вы описываете, больше похоже на архитектора.

Ответить
Развернуть ветку
1 комментарий
Pavel Borisov

Я бы сказал, что практически в любом деле очень нужны такие вот Т-образные специалисты, которые пусть не слишком глубоко, но одновременно охватывают несколько сфер.

Ответить
Развернуть ветку
Всвиторе

Фуллстек тяжко тянуть, поэтому их мало.

Ответить
Развернуть ветку
Bob Sinclar

раньше себя позиционировал как java developer. но мне всегда нравилось погружаться в то, как работает мой продукт от А до Я. и становился фулстеком. как работает АПИ, удобно ли мобильщикам? пытался сам сбилдит моб клиент. разворачивал фронт. шел к девопсам узнавать, почему наш регрес длится 2+ часа, оптимизировал скрипты. работал с DBA, чтобы понять, почему отчет долго грузится, в чем затык, могу ли на уровне приложения что-то закешировать и снять нагрузку с БД и тд.

затем, дальше искал такие же позиции, где мой подход работы работодатели заценят. и написал в резюме - Software Engineer. ибо это как раз то, чем занимаюсь на работе.

и если с ярлыком дажвист в неделю писали по 2-3 раза, то теперь пишут 1 раз в 2-3 месяца.

Ответить
Развернуть ветку
alex b
Проблема в том, что от программистов ждут разных навыков в горизонтальной черте — продуктовых, дизайнерских, управленческих и так далее, тогда как вертикальная черта по-старинке отвечает за все, связанное с инженерией.

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

Laravel — самый популярный на сегодняшний день PHP-фреймворк

Опять же автор либо не в теме, либо просто накопал нерелевантную инфу, самый популярный сейчас Symfony ввиду своей гибкости, кучи бандлов и мощного комьюнити

MongoDB для хранения данных в виде документов в формате JSON.

Какое-то странное понимание хранения данных, так можно и медиа файлы вместо s3 хранить в блобах в базе. Как минимум подобный подход ведет к дублированию данных в базе, а как максимум не дает нормально ими оперировать, в чем проблема хранить нормально данные и уже при запросе собирать json? В чем проблема кэшировать json если критична скорость его сборки? Я уже молчу о коровых ограничениях MySQL и монго в частности на длину поля

По поводу статьи - фуллстек всегда, повторюсь - ВСЕГДА будет проигрывать в квалификации команде узких специалистов, тупо потому что невозможно знать все и сразу. Да даже на примере js - node.js отличается от ванили или фреймворков вроде ангуляра и везде есть свои нюансы, да, писать можно, но какого качества этот проект будет - вопрос интересный. В современном мире фуллстеки имеют место быть на небольших проектах, если же вы пишете большую систему и комплектуете штат фуллстеками то либо система быстро превратится в кучу говнокода, либо фуллстеки сами между собой поделятся кто и над чем будет работать, что опять же ведет к бардаку в организации, но хотя бы проект будет жизнеспособен

Ответить
Развернуть ветку
Vit Mih

"самый популярный сейчас Symfony ввиду" — а можно ссылку на исследоваия по России? Говорят вот во всяких там европах, таки да, Symfony лидер. А в америках соединёных, вроде ларка (опять таки говорят). А в России ... тут обнаружится, что Yii2 делит первое_второе место с Laravel. Но это не точно )))

Ответить
Развернуть ветку
3 комментария
Rick

В вебе узкая специалищация доведена до абсурда. В сложные, крупные проекты нанимают прежде всего инженеров, которые глобально могут выполнить любую задачу вне зависимлсти от языка программирования. Поэтому во всякие гуглы, фэйсбуки и яндексы такой отбор, где заставляют решать алгоритмы на листочке. Конечно, потом по распределению такой специалист может сесть писать формочки. Но в любое время, его могут взять и поставить (предварительно проведя интеграцию в проект) писать приложение на С и т.д., если потребуется бизнесу. Про говнокод и "чистоту" кода тоже чушь, которую, зачастую, изобретают люди с маленьким опытом у себя в голове, что бы потом писать в комментариях. Бизнесу плевать на это и видили бы вы эту чистоту на крупных проектах...откройте первые версии движка v8. А то, что вы описали по узкой специализации, это не программисты, а кодеры и разделение это нужно на галерах, что бы с заказчика взять побольше бабла, за всякие скрамы и продакт менеджеров, так как оплачивается размер команды(время).

Ответить
Развернуть ветку
1 комментарий
Андрей

не всегда, повторюсь - НЕ ВСЕГДА.
«но какого качества будет проект - вопрос интересный», как тогда можно утверждать, что фулстек всегда будет проигрывать узким спецам, если качество проекта под вопросом, м?

Ответить
Развернуть ветку
Иван Крючков
В современном мире фуллстеки имеют место быть на небольших проектах

На больших проектах full stack нет, есть T-shaped разработчики. Условно говоря, если ты бекендер, то ты можешь какие-то простые вещи поправить на фронтенде, при изменении контракта между беком и фронтом, поправить enum-ки, если это React+Redux, то понимаешь базовую архитекту, как данные проходят через приложение, можешь найти редьюсеры, екшены и прочее. Если наобарот фронтендер, то можешь на беке поправить модели, добавить нужное поле, которое вытаскивается из базы. Т.е. выполнять базовые действия на другой стороне.

Ответить
Развернуть ветку
5 комментариев
Иван Фейкович

full stack - это просто попытка компании покрыть две позиции, одним человеком.

Ответить
Развернуть ветку
Артем Салютин

А еще фулстека точно можно накормить одной пиццей

Ответить
Развернуть ветку
Igor Kalashnikov

О том, что может один человек создать проект или нет.

Уже года два в свободное время разрабатываю генератор для проектов Angular + Nest + GraphQL

Идея такая
- используем монорепозиторий, чтобы все было в одном месте
- разбиваем приложение по энтити, например user, post, product
- для каждой энтити в соответствии с философией Nrwl делаем папочки feauture, ui, util, а также добавил route (для страниц и роутов) и api (он же backend) т.к. в Nrwl рассматривают только фронтенд
- каждая энтити нуждается в наборе компонент: card, edit-card, list, tree, table, и crud на бэке (какие компоненты нужны конкретной энтити можно настраивать, по умолчанию набор для crud)
- компоненты должны иметь smart/dumb части
- для лучшей связанности и шаринга интерфейсов использую graphql

На входе json описание моделей и их связи на выходе вот такой проект и код

Ответить
Развернуть ветку
Ilya Tkachenko

"Специалист подобен флюсу: полнота его односторонняя"
101-й афоризм из собрания мыслей и афоризмов «Плоды раздумья» (1854) Козьмы Пруткова.

Ответить
Развернуть ветку
RomanistHere

У меня вышел NEST a-ka Node + Express + SvelteKit + Tailwind, хз кто-то его ещё так называет или нет, но я очень доволен, хотя экспресс планирую поменять в будущем

Ответить
Развернуть ветку
Артем Салютин

Если express на nest.js менять, то получится какая-то рекурсия в названиях :)

Ответить
Развернуть ветку
1 комментарий
Yevgenia

Спасибо за такое подробное объяснение! Когда я только начинала учить React и работу с Node.js, у меня возникал вопрос, насколько серьезные приложения я смогу создавать с ними

Ответить
Развернуть ветку
Предельный колос

Получилось ответить на него уже?

Ответить
Развернуть ветку
2 комментария
Artem Petrenkov
Лучше определить, какой из стеков вам подойдет. Сложная логика на бэкенде со стандартными интерфейсами? Выбирайте VILT. Одностраничное приложение со сложным интерфейсом, но простой серверной частью? Выбирайте ME(A/R/V)N-стек.

А если сложная логика на бекенде и сложный интерфейс, то не берите ни ноду, ни тейлвинд :)

Ответить
Развернуть ветку
RomanistHere

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

Ответить
Развернуть ветку
8 комментариев
Sergey T

Спасибо, очень структурированно и доходчиво; мне как одновременно финдиру- и .net-фулстеку очень близка позиция :)

Ответить
Развернуть ветку
Artem Petrenkov
Vue.js — простой в освоении JS-фреймворк, который предоставляет много готовых компонентов;

Но качество компонентов в среднем хуже, чем у готовых компонентов для React. Кроме того, часть библиотек до сих пор висит на Vue 2, тогда как другая часть уже перешла на Vue 3.

Ответить
Развернуть ветку
Nikita Sergienko

Full Stack разработчик очень растяжимое понятие, с этого стоило начать. В статье идёт речь преимущественно о web-разработке, в этой области full stack-ом стать проще, чем в более специфических областях. Если брать web разработку, то каждый разраб должен быть от части full stack. По крайней мере на уровне понимания как всё работает на каждом уровне. Знание смежных областей сильно упростит понимание проекта в целом. Глубоко углубляться в каждый уровень разработки сложно, есть риск стать мастером на все руки, который толком ничего не умеет. Однако базовые технологии и принципы изучить возможно. По этому не считаю, что full stack вымирающий вид. Всё зависит от области разработки

Ответить
Развернуть ветку
Денис Акулов

Еще бы указали на каком уровне нужно все это знать ))

Ответить
Развернуть ветку
Vit Mih

Нужно знать всё, уметь чинить ноуты у бухгалтерши в том числе. Да, те самые преславутые картриджи кто будет заправлять? Конечно ФУЛСТЕК!

Ответить
Развернуть ветку
Руслан Астратов

Всем привет

Работаю фронтенд-разработчиком (React), при этом в свободное время изучаю Nest.js

Вопрос: обязательно ли для начинающего бэкендера (на Nest.js) знать и уметь работать с брокерами сообщений / уметь разворачивать инфраструктуру вокруг бэкенда / выполнять миграции баз данных?

Хотел записаться на курс , который недавно нашёл

https://netology.ru/programs/nodejs#/main ,

но пока сомневаюсь

Я не уверен в том, что в программе перечислены все важные пункты

Кто в теме, подскажите, пожалуйста, что нужно знать начинающему Nest.js разработчику. Какими навыками он должен обладать

Ответить
Развернуть ветку
Максим Пряников

Сердце бекенда это данные, то есть база. Миграции знать конечно надо.

Ответить
Развернуть ветку
Akim Glushkov

Так где закат-то в статье?

Ответить
Развернуть ветку
СлавалС

Узкие специалисты нужны при разработке каких-то фреймворков или чего-то действительно серьзьного, для обычного приложения достаточно команду к оторой есть относительная специализация, кто-то хорошо знает веб и может подсказать, но при этом у других нет проблем с js/html/css, кто-то отлично знает базы, но опять таки фронтендер понимает что такое нормализация, индексы, ксластеризация и план запроса и в общем случае запрос может написать себе сам, ровно как и с бэкендщиком.
тем более что когда работаешь с каким-то технологиями - обязан их знать.

Ответить
Развернуть ветку
Ivan Sergeev

Webpack - это не фреймворк, а вот Bootstrap и Material UI как раз фреймворки.

Ответить
Развернуть ветку
Предельный колос

Библиотеки, если быть точным. UI библиотеки.

Ответить
Развернуть ветку
Ведущий браслет
MongoDB для хранения данных в виде документов в формате JSON.

Вот это, кстати, неправда. MongoDB не хранит документы в JSON, а в BSON - несмотря на схожесть названия, это совершенно другой бинарный формат (JSON текстовый).

Условный программист C# или Java, работает с MongoDB используя библиотеку, называемую драйвером, который общается с базой данных, используя BSON и (ди)сериализует данные в пользовательские объекты. JSON вообще не принимает здесь участия.

Можно, конечно, использовать Atlas Data API и передавать/получать данные в JSON или Atlas Realm и работать c GraphQL.

Ответить
Развернуть ветку
Максим Пряников

Интересно, а на монге реально вообще сделать полноценный сервис? Ну, так чтобы было больше пары эндпоинтов и не было других баз.

Ответить
Развернуть ветку
Igor Kalashnikov

Все реально, на сколько оправдано другой вопрос))

Ответить
Развернуть ветку
Читать все 55 комментариев
null