×

Карьера в IT: должность Full Stack разработчик

Продолжаем серию «Карьера в IT»: разберемся, кто такие Full Stack разработчики, почему в компаниях возникает такая позиция и какие есть преимущества и недостатки у специализации.

Об этой предметной области нам рассказали разработчики с опытом Full Stack: Владислав Фурдак, Алексей Голубев, Вячеслав Лобода, Владимир Сподарик, Геннадий Догаев и Андрей Роговский.

Особенности направления

Full Stack Developer — это универсальный программист, который может сам с нуля разработать функциональный продукт. Такой специалист разбирается как в Back-end составляющей (программно-аппаратная часть сервиса), так и во Front-end (интерфейс пользователя).

По сути, разделение на Back-end и Front-end появилось только в 2010-х годах, когда программные продукты стали иметь сложную и многоуровневую структуру. До этого большинство программистов по умолчанию выступали в роли Full Stack, хотя так их никто не называл.

«В 90-х программистов было слишком мало, чтобы разделять их на какие-то категории. Я хотел делать видеоигры, но тогда еще не было готовых движков вроде Unity. И мне пришлось написать графический редактор, ассемблер, отладчик и игровой движок — то есть все этапы от А до Я» (Андрей Роговский).
«Даже если брать классическое образование программиста, студентов учат всему: от Assembler и баз данных до процессов управления SDLC. В значительной мере это и есть Full Stack» (Владимир Сподарик, Senior Full Stack Developer).

Сейчас компании открывают позиции с требованиями Full Stack по нескольким причинам. Например, проект не очень сложный технически, но имеет непростую доменную логику и требует частых изменений. То есть главная загвоздка — «что» именно нужно сделать, а не «как». Тогда одному человеку будет проще разобраться и сориентироваться.

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

«Часто при решении задач веб-разработки возникает необходимость вносить правки одновременно и во Front-end, и в Back-end. Для этого можно нанять двух разных специалистов или одного Full Stack разработчика. Последний вариант позволяет сэкономить время на коммуникацию» (Вячеслав Лобода, Senior Full Stack PHP Developer).
«Один Full Stack разработчик может сам деливерить большой кусок функционала. Ему не нужно договариваться об API и зависимостях в рамках одной фичи, как обычно бывает между Back-end и Front-end. Это позволяет сэкономить время» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).

Также решение может быть связано с особенностями проекта:

«Допустим, на проекте монолитная архитектура. И на Back-end используют серверный MVC-шаблонизатор. А Front-end состоит в основном из jQuery или AngularJS, Knockout, DevExtreme и так далее, которые навешиваются поверх той верстки, что приходит с сервера. В таком случае удобно, чтобы этим занимался один и тот же человек» (Владислав Фурдак, .NET Developer в DataArt).

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

Задачи и обязанности

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

«Я как Full Stack TeamLead провожу ревью кода и участвую в проработке реализации и Front-end, и Back-end. Это удобно, так как ты видишь более полную картину приложения» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).
«Я беру на себя весь Back-end и Front-end проекта. Но когда пришел на проект, Front-end часть уже была готова. Так что я только вношу необходимые правки и добавляю некоторые Front-end блоки по необходимости. К примеру, недавно нужно было вносить правки в код видеоплеера, написанном на JavaScript. Разобрался с этой задачей без особых проблем» (Вячеслав Лобода, Senior Full Stack PHP Developer).

В зависимости от компании, на проекте бывает разное соотношение задач по Back-end и Front-end. Требования к знаниям обоих направлений тоже могут отличаться. Например, Back-end — на уровне Senior, Front-end — на уровне Middle.

«Физически сложно знать на максимальном уровне и Back-end, и Front-end. Задача Full Stack разработчика — уметь самому написать проект, который будет визуально быстрым для пользователя (Front-end не тормозит, Back-end отвечает в пределах 500 мс, в редких случаях дольше) и защищенным (Back-end нельзя взломать, просто сформировав руками запрос). При этом Full Stack разработчик может не уметь, например, делать красивые анимации на Front-end, сложный автоматизированный деплой, серьёзные оптимизации Back-end и баз данных, когда нужно выжать из „железа“ максимум» (Геннадий Догаев, Full Stack Web Developer).

«Хороший Full Stack разработчик имеет разноплановый опыт, который покрывает весь цикл разработки решения. Он часто может и сервер настроить, и API реализовать, и интерфейс „дружественный“ сделать. И не по последним best practices, но в целом качественно» (Владимир Сподарик, Senior Full Stack Developer).

Преимущества и недостатки

Среди преимуществ специализации Full Stack разработчики отмечают скорость разработки, возможность самостоятельно решать задачи и не тратить дополнительное время на коммуникацию.

«Нравится, что могу создавать веб-приложения в одиночку, меньше задержек при работе. Например, когда работаешь как Front-end и нужно, чтобы Back-end отдавал новые данные, ты просишь коллегу внести изменения, ждешь. Full Stack разработчику ждать никого не нужно. Взял и сделал как надо» (Геннадий Догаев, Full Stack Web Developer).

«Привлекает то, что ты можешь сконцентрироваться на решении проблемы, а не холиварах или „выдавливании“ дополнительных процентов производительности по сравнению с другим фреймворком» (Владимир Сподарик, Senior Full Stack Developer).

Еще один плюс — гибкость при выборе проектов:

«Меня привлекают в этой специализации большие карьерные возможности: я более гибок в выборе проекта и моей роли в нем» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).

Из недостатков Full Stack разработчики подчеркивают, что на обучение им приходится тратить больше времени, чем если бы они работали с Back-end или Front-end по отдельности. Также бывает, что заказчики выставляют слишком много требований.

«То время, которое я потратил на освоение Front-end, можно было применить на более глубокое изучение Back-end. Например, освоить ещё один фреймворк или подучить алгоритмы и структуры данных. Но, собственно, ничего не мешает заняться этим в будущем» (Вячеслав Лобода, Senior Full Stack PHP Developer).

«Самый большой недостаток — распыление между специализациями. Большинство таких специалистов не так сильно развиваются в каком-то из направлений. Также может страдать качество кода, если от Full Stack разработчика требуют решение задачи на вчера, некогда сесть и разобраться, как же правильней это сделать» (Владислав Фурдак, .NET Developer в DataArt).

«Заказчики хотят свалить на одного человека слишком много. Например, уже встречаются объявления Node.js + React.js + React Native, то есть к веб-стеку добавляется ещё и мобильная разработка. Это влияет на качество знаний и конечного продукта: чем больше технологий нужно охватить, тем поверхностнее знаешь каждую из них. Кроме того, человеку не могут нравиться все направления одновременно. Мне из этого набора не очень интересна мобильная разработка» (Геннадий Догаев, Full Stack Web Developer).

Как стать Full Stack разработчиком и куда двигаться дальше

Большинство Full Stack разработчиков — это выходцы из Back-end, которые по мере необходимости сталкиваются с Front-end задачами и учатся их решать.

«Я думаю, это обусловлено тем, что порог входа во Front-end для Back-end разработчиков ниже, чем наоборот, особенно для решения тривиальных задач. А если человек работал только с Front-end, то разобраться в Back-end, базах данных, инфраструктуре для решения каких-то целостных задач будет на порядок сложней» (Владислав Фурдак, .NET Developer в DataArt).

Самые распространенные стеки технологий — .NET, PHP или Node.js + JavaScript. Но конфигурации могут быть какими угодно, лишь бы позволяли разрабатывать весь продукт целиком.

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

«Наращивайте компетенцию постепенно, с небольших задач. Пройдите курс по недостающему вам направлению, чтобы вникнуть в базовые принципы. А дальше осваивайте знания на практике по правилу Learning by doing» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).

«Самый простой способ стать Full Stack разработчиком — попробовать самостоятельно разработать пет-проект, который решает какую-то проблему. Это может быть плагин, сайт, утилита, бот — что угодно. После нескольких успешных проектов освоите концепцию или же поймете, что это не ваше» (Владимир Сподарик, Senior Full Stack Developer).

Конкретные рекомендации о том, как стать Full Stack разработчиком, зная Back-end, Владислав Фурдак собрал в отдельной статье.

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

«Я бы, наверное, не советовал новичкам сразу становиться Full Stack разработчиками. Лучше начинать с чего-то одного: Front-end или Back-end, а дальше уже по мере необходимости осваивать смежные области. Потому как при попытке развиваться „в ширину“ можно недобрать достаточной „глубины“ и в итоге превратиться в „разнорабочего“, который умеет делать все, но недостаточно хорошо» (Вячеслав Лобода, Senior Full Stack PHP Developer).

«Не думаю, что уровень Junior, Middle или Senior, которые используют в аутсорсинговых компаниях, как-то влияет на то, может ли разработчик быть Full Stack. Хороший Junior тоже способен залить свой Django-блог на Heroku» (Владимир Сподарик, Senior Full Stack Developer).

Разделились мнения опрошенных программистов и насчет зарплат:

«Я бы не сказал, что зарплаты Full Stack разработчиков выше, чем бэкендов или фронтендов» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).

«Я работаю на фрилансе, позиционирую себя как Back-end разработчик с дополнительными навыками Front-end. Эти дополнительные навыки позволяют мне более эффективно решать задачи и, соответственно, несколько повышают ценность меня как программиста. Если грубо прикинуть, это дает увеличение рейта на 15%» (Вячеслав Лобода, Senior Full Stack PHP Developer).

На момент публикации на DOU открыто 223 вакансии по направлению Full Stack, причем в 157 из них ищут специалиста с опытом от трех лет. По отдельным специализациям вакансий больше: например, 240 по .NET, 296 по PHP, 434 по Front-end.

«Однако у Full Stack разработчиков больше опций при поиске проекта: я могу искать работу как по Full Stack, так и по Back-end или Front-end по отдельности. К тому же спрос на Full Stack растет, поскольку такие люди максимально гибкие в плане проекта» (Алексей Голубев, Team Lead Full Stack Developer в GlobalLogic).

Из Full Stack специалистов получаются хорошие тимлиды, способные решать кросс-командные проблемы, а также лид-разработчики, способные «тащить» проекты в одиночку. Также можно бесконечно развиваться «по горизонтали»: изучать новые технологии, устраиваться на более сложные проекты.

Другие варианты — уйти в архитектуру, менеджмент или даже стать СТО стартапа. Широкие знания Full Stack разработчика помогут видеть сильные и слабые стороны проектных решений. К тому же за время карьеры человек накопит много знаний по самым разным технологиям и ему будет из чего выбрать при планировании проекта.


Иллюстрации Ульяны Патоки

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному6
LinkedIn

Схожі статті




50 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Скоріше Full Stack це терапевт. Якщо у вас кашель, то ви не побіжите зразу до пульмонолога. Аналогічно, якщо ви розробляєте MVP вам в 90% випадків не потрібен окремо гуру БД, бекенда і фронтенда, їм там просто буде нічого робити.

Або можливо сімейний лікар

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

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

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

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

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

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

Миф здесь на самом деле состоит в том, что языки и технологии — это сложная вещь, сакральные знания доступные только высокооплачиваемым специалистам. Это и есть миф распостраняемый дутыми сениорами, которые де-факто работают на уровне джуна, минимизируя свою отдачу. На самом деле там даже не 1/10 того что знает врач (даже стоматолог) или оператор котла на электростанции, и возможность построения успешной карьеры в айти без какого-либо образования это подтверждает.

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

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

Господи, что за ахинею ты несешь, если стоит задача сделать КАЧЕСТВЕННЫЙ продукт, то без полноценной работы всех спецов тут не обойтись, у меня был проект где я был фуллстек, но при разработке этого проекта я прекрасно понимал, что для этого проекта необходим дополнительно хороший ДБА дев и хороший фронт, поскольку моих знаний было недостаточно чтобы сделать КАЧЕСТВЕННЫЙ продукт. Я постоянно говорил об этом руководству об этом, мне же в ответ говорили что все прекрасно понимают, но ЗАКАЗЧИК не хочет выделять на них бюджет, в результате конечный результат вышел посредственным.

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

Господи, что за бред ? зачем нанимать еще 2 фуллстеков если можно нанять хорошего ДБА и хорошего фронта для решения тех же задач ?

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

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

Сколько бы терапевтов (фулл стек в мире медицины) вы не взяли на сложную операцию на сердце, КАЧЕСТВЕННЕЕ сделает узкопрофильный кардиохирург.

увольнять их и нанимать двух бекендеров?

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

Сколько бы терапевтов

применение аналогий в качестве аргумента — классика демагогии

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

и зачем вообще нужен младший медицинский персонал?

и кто отвечает за:
Послеоперационная смертность определена как любая смерть , независимо от причины, происходящим в течение 30 дней после операции в или из больницы. — хирург что проводил операцию?

подсказка — медики между собой часто исключают хирургов — из врачей. а записывают в «мясники»

хотите еще обсудить аналогию про терапевтов? ;)

вы мыслите категориями аутсорса,

я там не работал.
основная часть карьеры — позаказная разработка.

Если вы работаете над одним продуктом

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

применение аналогий в качестве аргумента — классика демагогии

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

почему количество терапевтов значительно превышает количество узкоспециализированных кардиохирургов?

нужно закрывать дыры?

и зачем вообще нужен младший медицинский персонал?

я думаю на этом можно прийти к консенсусу ― фулл стек это младший «мед.» персонал, который занимается поддержкой, залатыванием, но никак не «лечением»

медики между собой часто исключают хирургов — из врачей.

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

позаказная разработка.

читай аутсорс/фриланс

учитывая ваше представление о разработке, пришлось приводить аналогию

у меня тесть и жена — медики. так что туфта ваша аналогия :)
рассчитана на тех кто не в курсе что такое — лечение людей.

нужно закрывать дыры?

специализированный хирург даже диагноз часто поставить не сможет :)

я думаю на этом можно прийти к консенсусу ― фулл стек это младший «мед.» персонал, который занимается поддержкой, залатыванием, но никак не «лечением»

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

Чушь. Давайте пруфы ...

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

а «мясник» обидится и предложит гомеопатию

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

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

читай аутсорс/фриланс

ну, тогда бОльшая часть разработчиков занята в аутсорсе и фрилансе

в том числе и всяких IBM выигрывающих гос тендеры на разработку и установку дата центров для гос структур.
и т.д. и т.п.

а вы наверное ПО писали только для сферических коней в вакууме, да.

Если у Вас проект не требует постоянно переписывать хранимки (а всем лучше если он этого не требует), для чего вам ДБА? ДБА нужен после MVP, когда уже точно-точно понятно что и как этот продукт должен делать. И ДБА там нужен либо нарисовать правильную структуру БД (если решили переписать всё с нуля), либо вообще только проконсультировать по оптимизации узких мест. На каждый день для ДБА в среднем веб-проекте просто-напросто нет работы, и я не могу пока представить проект где она бы была.

А второе, опять таки, владение полным стеком — это характеристика профи

Это скорее характеристика ноулайфера. Потому как ни один нормальный человек, если он не гений и не задрот, не может СТОЛЬКО времени тратить на то что бы постоянно следить и развиваться и в беке и во фронте! Это просто не реально.

если стоит задача сделать КАЧЕСТВЕННЫЙ продукт,

качественность продукта — это оценка потребителями.

со стороны же вкладывающего деньги, качественность это

отношение фукционала к затратам. чем это отношение выше — тем продукт качественней.

а что вы вкладываете в понятие — «КАЧЕСТВЕННЫЙ продукт»?

чтобы сделать качественный продукт, нужно, как выше было сказано:

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

то есть — профессионалом, а не «таскозакрывателем», как я называю этих: «Дутый сениор закрывает тикет»

в результате конечный результат вышел посредственным.

это оценка заказчика, или ваша программерско + инженерная = перфекциониская?

1. не к чему придраться, придерусь к орфографии
2.

отношение фукционала к затратам. чем это отношение выше — тем продукт качественней.

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

Тезис выше про экономию, а не про качество. Вспоминаем:
media1.tenor.com/...​0482f7b941c5a6e/tenor.gif

бред сивой кобылы.

это перифраз положений ISO с точки зрения — производителя. Производителя интересует — прибыль. Производитель не будет удовлетворять желания потребителя в ущерб себе.
так и появляется — знаменатель в формуле.

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

а что обычно отвечают программисты о том — ПО качественное или нет?
обычно — код фиговый, архитектура не та, доки нет, ЯП не тот выбран, и прочее — не имеющие никакого отношения к определениям выше.

Функционал либо удовлетворяет ожиданиям клиента, либо нет, и абсолютно всё равно сколько он вложил денег.

а ЗАКАЗЧИКУ — соооовсем не пофиг

Заказчик не называет это словом «качество», а говорит «экономия». Следим за логической цепочкой:

1. качество это удовлетворение потребностей клиента
2. фулл стек не может сделать качество, потому что ему не хватает знаний, код полон багов и/или нереализованного функционала
3. продукт не качественный

Функционал либо удовлетворяет ожиданиям клиента, либо нет, и абсолютно всё равно сколько он вложил денег.

сколько бы заказчик не потратил денег на фулл стека, продукт остался не качественным

Заказчик не называет это словом «качество», а говорит «экономия»

качество = функциональность / затраты
да, заказчик естественно хочет уменьшить — затраты

поэтому он говорит об — «экономии»

Следим за логической цепочкой:

1 качество это удовлетворение потребностей клиента — с учетом ограничений в затратах на это удовлетворение — деньги и время.
2 фулл стек не может сделать качество — может реализовать функционал, иначе какой он нафик фулстек тогда. и сделает это дешевле чем 2 узких специалиста. Или 2 фулстека — сдалают это быстрее, при той же цене, потому что будут меньше трансакционные издержки. гуглить так же тему — «кроссфункциональные команды»
3. продукт удовлетворяет — пользователя, и как менее затратный — того кто вложил деньги в его разработку. бинго!

сколько бы заказчик не потратил денег на фулл стека, продукт остался не качественным

некачественный продукт это:

1. не удовлтетворивший клиента
2. не принесший прибыли вложившему деньги

Оба пункта в разработке ПО чаще проваливаются не по тому кто делал, фул стеки или специалисты, а по просчетам маркетинга, и менеджментским причинам:
Большинство наших неудач, к примеру, приписывается менеджменту. И большую часть наших успехов можно приписать менеджменту. В своей замечательной книге, посвященной принципам разработки ПО, Алан Дэвис говорит об этом очень ясно в принципе 127: «Хороший менеджмент важнее хорошей технологии». Мне тяжело это признать, но Эл прав.
«Факты и заблуждения профессионального программирования» Роберт Гласс

У нас с вами непримиримо разные взгляды на термин «качество», поэтому дискуссия не имеет смысла.

У нас с вами непримиримо разные взгляды на термин «качество»

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

Интегральный показатель качества продукции (I) представляет собой отношение суммарного полезного эффекта от использования продукции по назначению (Пэ) к суммарным затратам на ее создание (Зп) и эксплуатацию (Зэ)

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

и
Традиционное управление затратами подразумевает контроль затрат лишь на стадии производства, однако большинство затрат «закладывается» еще на стадии разработки и проектирования.
...таргет-костинг ... кайдзен-костинг
«Система менеджмента Тойоты»

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

и на разработку ПО — я так же смотрю.
не вижу почему я должен смотреть на разработку ПО по другому, если на него так же смотрят и заказчики этого ПО :)
заказчики — это те кто платит деньги.
а не программисты которые получают эти деньги и рассуждают об абстрактном идеале инженерного качества.
недостижимом конечно идеале :)

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

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

Ахинею какую-то несёте

Согласен) Мое мнение что код полон багов и/или нереализованного функционала из-за плохой квалификации команды а не того, backend/frontend или fullstack разработчик пишет код. Есть уйма backend разработчиков которые пишут код, который невозможно поддерживать... И их знания явно не делают с них первоклассных «хирургов» (демагогия из других комментариев).
Всё это очень ситуативно...

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

воу-воу полегче) даже вспомнилось такое понятие over motivated underachiever — и я таки кажется начал понимать о чем оно.
Вася за 15 лет поработал с десятком ынтырпрайз-проектов, освоил многопоточность, машинное обучение и нейронные сети, математическую лингвистику, теорию и практику работы распределенных систем, вошел «глубоко» в несколько предметных областей, но программировал в основном (черт!) на джаве,
а что там Петя за 3 недели освоил, синтаксис джавы + пару классов из java.core???

На практике таких Василиев как у тебя довольно немного, среднестатический «бек-енд гуру» Вася 15 лет протирал штаны, гонял чаи, делал minimum viable job всем своим видом подавая что его деятельность очень сложна, поэтому у него нету времени на девопс и, ну совсем нет сил понимать что там на фронте.

Суть в том, что любой толковый разработчик рано или поздно столкнется со сферами вне его специализации и освоит их. А те кто не осваивают, — это в 90% случаев не от того, что они глубокие специалисты, а от того что они просто минимизируют свою отдачу и от того как легко в айти избегать ответственности.

На практике таких Василиев как у тебя довольно немного, среднестатический «бек-енд гуру» Вася 15 лет протирал штаны, гонял чаи, делал minimum viable job всем своим видом подавая что его деятельность очень сложна, поэтому у него нету времени на девопс и, ну совсем нет сил понимать что там на фронте.

В этом высказывании можно заменить «бек-енд гуру» на переменную и подставлять что угодно и фраза останется валидной: бек-енд, фронт, фуллстэк, BA, менеджер...

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

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

А с чего вы решили что узконаправленные специалисты не трогают другие области? Многие имеют свои проекты с использованием других технологий/областей/платформ, контребьютят в OpenSource, пробуют интересные темы не по специализации. Просто они указывают эти знания как вторичные в резюме, а не пишут что они фуллстэк.
Более того, есть люди которые получают дополнительные знание совсем не из сферы IT(например психологии, социологии и т.д.) И чем плох узкоспециализированный разработчик с дополнительными знаниями в псохологии? Наоборот, я считаю он более гибкий т.к. не зацикливается только на одной индустрии. Но при этом он все еще только, например, бэк-энд разработчик и все.
Но да, не все такие, есть много и таких, которые выучили что то одно и напрочь не хотят учить что то новое.

На практике таких Василиев как у тебя довольно немного, среднестатический «бек-енд гуру» Вася 15 лет протирал штаны, гонял чаи, делал minimum viable job всем своим видом подавая что его деятельность очень сложна, поэтому у него нету времени на девопс и, ну совсем нет сил понимать что там на фронте.

Вы статистику собирали? Делали соцпоросы на доу? Или у вас просто пару таких знакомых Вась, и теперь вешаете этот ярлык на весь окружающий мир?

Возможно, я разрушу твоё представление о мире) Но чаще это работает так: Вася за 15 лет сидел на 1 месте и педалил код никак не развиваясь и к своим 35-40 дорос до довольно среднего и посредственного уровня)

найн, вообще не в ту степь) там ниже за меня уже правда написали

как бекенд (Вася), так и фулстек (Петя) может быть хорошим, плохим, посредственным, гуру, просиживальщиком штанов (отсиживателем часов) и т д, как и админ, менджер, тестер или сантехник

смысл был в том, что по набору фактов «Вася 15 лет писал на джаве» и «Петя освоил Васин стек за 3 недели» (хотя это уже очень смелое заявление) нельзя судить об их квалификации вообще ничего, например Вася мог освоить все, что я написал выше, но пройти мимо ангулара, а Петя чуть чуть подергать и спринг и ангулар и заявить, что он теперь круче Васи

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

Это всё прекрасно выглядит на бумаге, а фактически ковырять новую технологию 3 недели ради Петиной забавы банально никто не даст. Именно нормализация подходов к разработке на локальном рынке и стирает эти сказки в порошок, оставляя вероятность процентов 10, что так получится, а нормализация вакансий именно что понизит качество, как бы кому-то этого не хотелось. Петя, конечно, может быть уверен, что его трёхнедельный говнокод — это верх профессионализма, но это уже проблемы Пети). Выходит, что этот а-ля «профессионализм» является банальной возможностью попасть на проект, где заказчик даст возможность выучить что-то новое за его же деньги, только это не является заслугой Пети, и другие разработчики вполне себе радуются подобным возможностям и успешно учатся — хоть фуллстек, хоть кто угодно. Если же под 3 неделями имеется в виду самообучение, то у Пети явно что-то не в порядке с оценкой своих знаний, и его влажные фантазии быстро разобьются о суровую реальность полевой разработки с костылями и нюансами за пределами освоенном Петей hello world, которые есть у 99% тулзовин.

бывает какой-нибудь самопальный js фреймворк, который вряд ли кто-то знает, поэтому в описании позиции пишут — Angular и/или React , подразумевая что опытный человек знающий паттерны фронтендов, разберется с чем-то новым для него

Глупо пытаться вернуться в начало 20 века. Если человек ищет волшебника-он находит сказочника. IT растет, сложность увеличивается, а значит фулстек будет отступать. С точки зрения заказчика — фулстек конечно круто — нет проблем в команде, денег надо меньше. Но всё уже ушло слишком далеко. Я смотрел видео техлида с компании Google. Даже он говорил, что не может быть спецом больше, чем в одном языке одновременно. Опять же -если ты работаешь везде-то будь готов обновлять свои знания везде ,а это УЙМА времени.Это даже не ноулайф — это надо мыться/есть/засыпать и слушать подкаст.

Тут есть такой нюанс. Принципы ООП они практически везде одинаковы. Например, человек знает Java, и он может легко выучить тот же TypeScript, потому что синтаксис похож.

Також варто пам’ятати, що Fullstack це не тільки про Web. Інтерфейси комунікації з користувачем можуть бути різні (Embdedded, IoT, Desktop, емейл, чат-бот, проста адмінка, тощо), іноді Web Frontend-у не потрібно взагалі. Хоч Web найчастіше й хочуть (з анімаціями і красивими переходами). Проте не всім потрібен варіант з (No)SQL + REST, а все решта на Frontend-і.

Однажды ученик спросил мастера:
— Правда ли, что бекендщик, ставший фуллстеком, всегда будет плохо знать фронт?
Мастер ему ответствовал:
— Нет никакого фуллстека.
После этих слов ученик стал просветленным.

Мастер ударил его мастерком

Из моего опыта общения с зарубежными продуктовыми компаниями:

  • Full stack === специалист про всё и ни про что. Таких берут на поддержку или допиливание продукта, когда мало денег.
  • Почти всегда стараются находить узконаправленных специалистов, чтобы делать качество, а не количество.
  • Тайтлом «full stack» там не гордятся, и в резюме такого не пишут ― это считается дурным тоном. Обычно рассказывают про опыт в front-end и back-end, но позиционируют себя в одном направлении.

Full stack разработчик ― явление популярное в outsource, потому что заказчики сюда приходят не тратить деньги. Как говорилось в самой статье:

умеет делать все, но недостаточно хорошо

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

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

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

...и деньги на зп

Собеседования показали, что FullStack’и массово жертвуют Cloud/DevOps частью ради фронта, имея очень туманное представление о чём-то за пределами обычных виртуалок и Docker Compose — про IAC и т.д. даже не говорю.

Мб не те люди шли на собеседование?

Разные шли). Просто в эти практики сейчас вникать не особо «принято» (один из кандидатов даже явно дал понять, что есть же DevOps’ы — пусть они и занимаются, разработчик этого делать не обязан), а в случае с FullStack было бы даже наивно ожидать подобное, т.к. всего знать нельзя, мозг не резиновый, и не каждый — Илон Маск. Люди, которые шарят, начиная с Cloud/DevOps (конечно, не на уровне выделенного инженера, но всё же), и заканчивая фронтом включительно — единичные случаи, поэтому они чаще всего либо являются тех лидами и дальше вверх, либо работают за деньги сильно выше рынка (получая фактически на уровне тех самых лидов и архитекторов). Я, например, делаю наоборот — жертвую фронтом.

Просто фронт — это то что видят и щупают и заказчики, и их клиенты в первую очередь. Бек — сердце проекта, без него ничего работать не будет. А на полноценный девопс уже просто сил не хватает. Я могу задеплоить проект руками на сервер — поставить зависимости, настроить nginx (включая load balancing, rate limiting), простые автоматизированные бекапы. Но каждый раз для этого приходится доставать туториалы и со скрипом вспоминать как это делается.

про IAC

Да все равно на одном проекте Puppet, на другом Ansible, и вероятность найти проект чтобы и по твоему бекенд стеку совпадал и по фронту и по девопс не слишком велика) Да и чтобы стать ± нормальным девопсом нужно потратить больше времени чем на фронт, документация одного только кубенетеса по обьему жирнее чем дока ангуляра. Но все же когда фронт не знает что такое реверс прокси и зачем это нужно — это действительно проблема)

Підписатись на коментарі