Я попробую высказать свою точку зрения о том, что фуллстек – это на самом деле клево, и почему по этому пути идти хорошо.
Возможно, кому-то текст ниже поможет встать на этот путь, а возможно и наоборот, убережет неокрепшие умы от него. В общем, добро пожаловать под кат.
**АХТУНГ! Все нижесказанное не является абсолютной истиной в последней инстанции и является моим субъективным видением (этого мира).
Для начала давайте определимся с терминами, о которых пойдет речь ниже, чтобы быть в одном информационном поле, т.к. понятие fullstack у всех разное (ровно как и разделение на Junior/Middle/Senior и прочие табели о рангах).
Наиболее часто встречается мнение, что fullstack – это разработчик, который в одно лицо может работать над проектом полностью своими силами, от бэка до фронта.
Некоторые из вас могут сказать «ну такое у меня в команде мидлы могут», что (мягко говоря) в большинстве случаев неверно. Если разработчик фронта может что-то исправить/добавить в коде бэка, поковыряться в запросах БД, это еще совсем не фуллстек.
Ведь разработка проекта – это не только код бэка и фронта, это еще и постройка/настройка/поддержка инфраструктуры для получившегося продукта. Мало написать код, его еще нужно заставить работать на объекте. А объектом может быть и 5-долларовая VPS с LAMP в дефолте, и облачные сети типа AWS/Azure, или вообще собственная инфраструктура, где живет вполне себе реальное железо, от серверов/рабочих станций до маршрутизаторов.
Поэтому речь пойдет не совсем о «fullstack-dev», а скорее о «fullstack-вообще». Который может тянуть в одно лицо проект от стадии переговоров, до стадии подписания акта о выполненных работах.
Я не буду загибать пальцы, перечисляя, что должен, а чего не должен знать fullstack-специалист, т.к. это крайне расплывчатый список. В конце концов, кто-то умудряется сдавать и продвигать «проекты одного инструмента», скажем на Java с NoSQL, но сегодня мы про такое не будем.
Итак,
Кратко пробежимся по плюсминусам, лежащим на поверхности.
Минусы
Вероятно, самый очевидный минус — примите как факт то, что вы всегда (всегда) будете уступать узкоспециализированным разработчикам во всем – от владения самыми современными тулами и технологиями, до качества кода. Если вы амбициозны, хотите всегда быть на острие прогресса, хотите гнуть пальцы
Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да? Тем не менее, в подавляющем большинстве случаев, так оно и есть (если конечно мы хотим использовать фуллстек, как фуллстек, а не как «программиста Java»). Там, где много платят с первых дней/месяцев работы, обычно не требуется «и швец и жнец, и на дуде игрец» — там требуется еще одна хорошо смазанная шестеренка в общий механизм, которая будет делать ровно одну задачу, и делать ее хорошо,
Работа в одну каску подразумевает конечность ресурсов. Т.е. вы не сможете реализовать по-настоящему крупный программный продукт. Даже если хватит знаний, не хватит времени. Вы не сможете выпустить убойную игру (мелкие инди-разработки бывают хороши, но речь не о них), операционную систему или «Mega-Office-XXL». Часто люди перегорают, если взвалили на себя слишком крупный проект, не рассчитав сил. Если вам нравится делать игры, или участвовать в крупных проектах (как правило международных), ну или на крайняк получать хорошую зарплату сразу после ВУЗа (2-3 лет активной работы) в какой-то одной области – вам тоже не сюда.
Вам все время придется учиться. Постоянно. Много. Разному. Если вы с содроганием вспоминаете годы учебы, конференции и вебинары вызывают у вас неприязнь, если вы не готовы тратить часы на чтение мегатонн информационного мусора, выискивая в нем крупицы полезного, если вас раздражают технологии, в которые придется суметь, вне зависимости от желаний и предпочтений – путь fullstack вам не нужен. Нужно понять (и принять), что здесь необходим некий дзен. Вы просто должны тащиться от происходящего, что бывает далеко не с каждым.
Никогда не забывайте, что человек, по сути, однозадачная скотинка, но вам придется постоянно эмулировать режимы многозадачности (разные языки, разные среды разработки, разные подходы, да сами концепции «написать код» и «развернуть инфраструктуру» — разные). Поверьте, поначалу это весьма сложно и приводит к низкой скорости и большому количеству ошибок.
И наконец, всегда есть риск остаться заложником ситуации и перестать развиваться, если место работы не предполагает каких-то карьерных лестниц. И многие тысячи потенциально отличных работников уныло сидят в небольших конторках, занимаясь совсем не тем, чем хотели 10 лет тому назад. Да, они умеют в Windows Server, в *nix, могут и в Java и Python, поддерживают какую-нибудь поделку на C#, давным-давно написан «корпоративный портал» на PHP+JS, но больше задач нет, у конторы все отлажено, все работает.
И стоит перешагнуть за рубеж в 35-40 лет, как включается встроенный в человеков консерватизм, помноженный на вот это уютное болотце, что в итоге и приводит к эдакому «чемодану без ручки». И разорвать этот порочный круг с каждым годом становится сложнее. Опасайтесь такого состояния, ибо борода и свитер отрастают еще быстрее, чем у узких специалистов, 10 лет пишущих на одном и том же.
Пожалуй, хватит на сегодня ужастиков, давайте о плюсах
Вы можете все. Ну или почти. От корпоративного сайта, до мобильного приложения. Ведь вы не ограничены 1-2 технологиями. Можете даже построить свою микро-империю в отдельно взятом интранете.
Если вы достаточно долго (и главное – успешно) работаете fullstack’ом, вы вполне себе можете возглавить команду разработчиков. Стать Архитектором. Тем, кто стоит у истоков любого крупного проекта.
Если вы угрюмый интроверт, любите машины и не любите людей – зарабатывайте деньги на удаленке. Неторопливо ведя несколько проектов, можно зарабатывать неплохие деньги, не тратя нервы на общение с командой.
Если вам нравится общаться с людьми, вы имеете подвешенный (или натренированный) язык (или вы просто хитрый интроверт с силой воли) – денег вы сможете заработать еще больше, проникая в душу заказчика.
Следует понимать, что совсем без работы вы не останетесь никогда. Если вы правильный fullstack, то уж на middle в любой технологии должны тянуть. А то и на «синьора средней руки» (это когда в Гугл тимлидом не возьмут с улицы, но в более-менее серьезный проект – легко).
И напоследок несколько простых и очевидных (увы, не всем и не всегда) советов. Я сознательно сделаю акцент на кодовую базу, а не на инфраструктуру, чтобы не утомлять читателей.
Совет первый. Не позволяйте своей гордыне превалировать над вами. Это очень важно. Примите как данность, что есть люди, которые делают что-то лучше вас. Учитесь у них, если это возможно. Подход «вы все говно, а я целый fullstack, я все могу» неверен в корне, и часто бьет не только по самолюбию, но и по кошельку. Если вы любите себя и деньги – следуйте этому совету.
Совет второй. Раз-другой в несколько лет было бы неплохо поработать в команде узких спецов. Это сильно поднимает скилл, ведь технологии на месте совсем не стоят, а несутся со скоростью локомотива, а узкие спецы стараются быть в тренде. Если есть такая возможность – не упускайте ее, многому научитесь, найдете уйму узких мест в своих старых проектах и не допустите их в новых.
Совет третий. Не стремитесь изучить ВСЕ ЯП. Во-первых, это просто невозможно, во-вторых, не нужно. Используйте в своих проектах хорошо изученные технологии, те, в которых вы действительно «синьор». Новые ЯП изучать нужно (хотя бы для общего развития), но применять их в реальных проектах следует только после того, как они станут вам действительно понятны. Как непосредственно языки и как то, с каким качеством их можно использовать, какую пользу можно извлечь от перехода скажем, с Java на Kotlin или Scala. Если вы не понимаете пользы, значит либо язык еще не созрел, либо (скорее всего) вы сами. Подход «дайте две недели на чтение спек и я буду писать на этом говне» — плохой подход.
Совет четвертый. Если вы смотрите на код своих разработок 1-3 летней давности и вам не хочется его исправить, скорее всего у вас кризис, как у разработчика (либо идеальный во всех отношениях код, чего не бывает). Попробуйте воспользоваться советом №2.
Совет пятый. С самого начала пути нарабатывайте клиентскую базу. Нарабатывайте свой авторитет. Вас и ваши разработки должны знать. При этом неважно, работаете ли вы на предприятии или фрилансите на удаленке. Если у вас нет сложностей с общением с людьми, обязательно потратьте время на общение с заказчиком. И вдвойне обязательно – на общение непосредственно с теми, кому предстоит работать с вашим продуктом. Так вы гораздо лучше сможете продумать архитектуру будущего проекта.
Совет седьмой. Соизмеряйте инструменты и задачи. Не стоит палить из пушки по воробьям. Не нужно разворачивать локальную инфраструктуру
Не нужно тащить из бэка на фронт то, чему место именно на бэке. Наоборот тоже не делайте. Помните, если у вас вдруг стало слишком много костылей на проекте, ТЗ которого не изменяли 100500 раз при разработке — значит, вы плохо спроектировали архитектуру. Если есть возможность — исправляйте, если нет — обязательно учитывайте это в следующих задачах.
Совет восьмой. Правильно расставляйте приоритеты. Помните, что ваша задача – сделать продукт, в первую очередь удобный и как можно более безотказный. Даже если у вас гипертрофированное чувство прекрасного, красоту нужно наводить в последнюю очередь.
Уф. Пожалуй для начала этого хватит.
Всем спасибо за внимание.
Ах да, чуть не забыл… Да начнется срач!
Комментарии (38)
Ascar
19.11.2018 20:51+1Ага, все мы немного фулстек… И штраф двойного класса на максимальный уровень в игре тоже присутствует.
Moxa
19.11.2018 22:29-3опять какие-то границы… почему я как фулстек обязательно должен быть хуже узкоспециализированного специалиста? Языки развиваются довольно медленно, фреймворки на них быстрее, но все равно апдейты выходят в лучшем случае раз в полгода. Сколько нужно потратить времени на изучение языка, чтобы пользоваться им на уровне синьора?
tsukasa_mixer
20.11.2018 00:08-1тут скорее не тот факт, что не можем, а тот что из-за объемов смежных знаний просто всего не успеть изучить, вот и получается что некоторые детали можно успеть только по верхам, с закладами на детали.
Впрочем это не означает что какой-либо набор технологий фулстек не может знать очень глубоко.
ZaEzzz
20.11.2018 08:30А где критерии лучше/хуже?
Если говорить о багаже знаний и скиллов, то, при прочих равных, вы всегда будете знать и уметь меньше, чем узкоспециализированный спец. Тут еще стоит учесть факт, что хороший узкий спец, разбирается в смежных областях как минимум на уровне джуна.
Crafter2012
19.11.2018 23:31А совет №6? =)
HerrDirektor Автор
20.11.2018 08:06Его я удалил в аккурат перед модерацией, ибо решил, что там написаны азбучные истины и выглядит он совершенно по-детски, не для местной аудитории :)
sndl
20.11.2018 01:15Как-то все переусложнено и большая поляризация. Все зависит от нужд проекта и требований к Вам
Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%
Также и технологиями, когда-то в начинующей компании я был сильно полезен как универсал. Появилась потребность масштабироваться, копать вглубь и развивать новые сервисы, я уже меньше подхожу и всячески пытаюсь избавиться от как можно больших направлений, чтобы оставить минимум для фокуса
Я занимаюсь элементами:
— стратегии
— продукта
— инфраструктуры
— общего бекэнда
— машинное обучение
— аналитика
Как результат:
— недостаточно времени для погружения в исследования по продукту
— я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
— когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
— я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
— в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.
В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал
HerrDirektor Автор
20.11.2018 08:03Да, все верно. Это и называется «конечность ресурсов». Т.е. вы уперлись в свой потолок производительности в рамках данного проекта (он перестал вмещаться в вас и требует дополнительных ресурсов) и совершенно логично сокращаете круг задач, чтобы повысить производительность. Я как раз об этом и писал:
Работа в одну каску подразумевает конечность ресурсов. Т.е. вы не сможете реализовать по-настоящему крупный программный продукт. Даже если хватит знаний, не хватит времени.
OxCom
20.11.2018 01:45-1Частично согласен с автором. Fullstack — выглядит как затычка в любой бочке. Эдакий и швец, и жнец, и на дуде игрец. Это смесь front-, back- и devops. Да, сложно изучать все. Да нельзя знать все, но ничего не мешает быть в каком-то сегменте технологий на самом «гребне волны».
Для меня есть несколько проблем:
1) Постоянно нужно учиться, что очень сильно влияет на личную/общественную жизнь.
2) Из-за №1 нужно постоянно распределять время на задачи: работа / учеба / семья /…
3) Постоянно находишься на краю выгорания
4) Постоянная борьба сделать все «правильно» и «доставить продукт / фичу вовремя»
Плюсы:
1) Можно найти решение задачи, которое будет проще / легче / быстрее / правильнее на стыке технологий, чем решение той же задачи в одной технологии. Например, отдавать файлы очень большие файлы с проверкой доступа по большому количеству правил.
2) Возможность разобраться в коде другого приложения, которые используется проектом и, возможно, исправить баг
3) Понимание того, как протекают процессы в более широком смысле. Не в рамках PHP или Java, а начиная с момента его формирования и заканчивая рендером.
4) Можно в любой момент заменить любого члена команды, пока тот болеет.
Совет: закладывайте правильную архитектуру с начала, но не пишите все сразу. Расставляйте приоритеты и планируйте.HerrDirektor Автор
20.11.2018 07:58Совет: закладывайте правильную архитектуру с начала, но не пишите все сразу.
Я тоже был сторонником этого совета, пока не научился хорошо эмулировать многозадачность мозга :)
Как пример — при работе с основным проектом (скажем, на C#), почти всегда открыт более мелкий, который на данный момент не критичен по времени (или вообще в рамках самообразования), например что-нибудь на PHP или JS.
Когда я упираюсь в производительность своей головы (нужно придумать правильный алгоритм работы, чтобы не превратить код в костыль, уперся в явное несоответствие архитектуры, просто устал делать этот проект), я без особого труда переключаюсь на второй (как правило, он гораздо легче в плане архитектуры и алгоритмов). Работаю в нем какое-то время (ментально отдыхая), пока мозг не скажет «ок, я кажется сообразил, что нужно сделать в главном проекте, погнали туда», или просто пока не почувствую, что снова готов погрызть сложный орех.
И знаете, вполне себе неплохо получается, не смотря на массовую критику знакомыми разработчиками такого подхода.
Понятия не имею, можно ли этому просто научиться или это какое-то особое строение/расстройство моего мозга.
У меня как-то само сложилось во времена, когда я был молод, глуп и жаден (и брал на себя больше, чем получалось унести).
vagon333
20.11.2018 07:32Еще одно важное преимущество Full Stack: шанс создать свой продукт или партнерство в создании продукта.
peresada
20.11.2018 08:18А ведь еще несколько лет назад fullstack'и назывались эникейщиками. Казалось бы — суть одна, зато как теперь гордо звучит.
roscomtheend
20.11.2018 13:47А админы — программистами, мониторы — процессорами, есть много вариантов неверных названий от непонимающих людей.
AndreyGaskov
20.11.2018 08:31А ведь еще несколько лет назад fullstack'и назывались эникейщиками. Казалось бы — суть одна, зато как теперь гордо звучит.
Несколько лет назад — это сколько? Вроде бы я в профессии уже больше 15 лет, но никогда ни разу не слышал, чтобы fullstack'а называли эникейщиком. И суть совершенно разная. Скорее даже наоборот, лет 10 назад было вполне нормальным, что разработчик пишет и бэк (включая БД) и фронт (хотя, может это так мне повезло). Но сейчас всё усложнилось сильно, особенно фронт, и теперь очень сложно быть сильным во всём.peresada
20.11.2018 08:36А в чем разница между эникейщиком и fullstack'ом, описанным в статье?
AndreyGaskov
20.11.2018 08:44А в чем разница между эникейщиком и fullstack'ом, описанным в статье?
Думаю, что в «официальных» словарях такого слова нет, народные интернет-словари дают такие определения:
эникейщик — Название должности «специалиста по всему» в области компьютеров, оргтехники, телефонии, не требующей углублённых знаний. Он решает мелкие простые повседневные проблемы рядовых пользователей, чтобы не отнимать ценное время у админов
эникейщик — помощник системного администратора или сотрудник техподдержки (в основном занимается тем, что разбирается с пустяковыми проблемами пользователей; происходит от названия несуществующей клавиши any key, которую система просит нажать...
эникейщик — шуточное название штатной должности работника, обязанностью которого является техническая поддержка пользователей компьютера внутри компании
Т.е. совершенно ничего общего с тем, что написано в статье. У вас, конечно, может быть своё собственное определение, но не вижу смысла это ваше личное определение обсуждать.peresada
20.11.2018 09:01Первое же Ваше определение довольно сильно схоже с тем, что описано в статье и в Вашем же комментарии. То есть человек, который и сервер поднимет, и базу, и бекенд, и фронтенд, правда все это будет на относительно низком уровне, что нормально для малого бизнеса и легких приложений, то есть по сути он действительно решает любые задачи в своей области, которые не требуют более углубленного подхода и по сути являются «простыми».
HerrDirektor Автор
20.11.2018 09:53Здесь все зависит от того, как вы видите этот «низкий уровень». Поделитесь вашей шкалой, чтобы иметь общее представление, стоит ли вступать с вами в дискуссию?
peresada
20.11.2018 10:04Я не зря написал "относительно низкий уровень" (Вы ведь сами согласны с утверждением, что fulltstack слабее в определенной области по сравнению с узконаправленным специалистом). Грубо говоря, у приложений, которые под ключ сделаны одним человеком, имхо всегда много мелких косяков (если говорить про малый бизнес) во всех областях:
— В базе индекс бесполезный поставил, или не поставил полезный, или по поводу архитектуры особо не заморачивался
— Во фронте какая-то форма криво отображается при определенном поведении
— В бекенде не подумал о масштабировании
— В сервере забил на какие-то настройки
И для малого бизнеса и не нагруженного приложения — это не страшно, но как только приложение начнет расти — эти казалось бы незначительно косяки выше начнут скапливаться в нехилый технический долг со временем. И в зависимости от опыта изначального разработчика могут привести к более серьезным проблемам.HerrDirektor Автор
20.11.2018 10:46Грубо говоря, у приложений, которые под ключ сделаны одним человеком, имхо всегда много мелких косяков (если говорить про малый бизнес) во всех областях
Мягко говоря, это не совсем правда.
Все перечисленные проблемы встречаются в абсолютном большинстве крупных и не очень продуктов, над которыми работает команда «не-аникеев». И криво спроектированные БД, и кривой фронт. И костылей в исходном коде встречается даже побольше, чем в «коробке одного работника».
И зависит это в большинстве случаев не от того, сделан ли продукт одним человеком или командой, а
в зависимости от опыта изначального разработчика
Чем выше опыт, тем меньше ошибок.
Проблема (а скорее ограничение) fullstack не в подходе к проектированию, даже не в качестве кода, а в том, что после определенного предела масштабов проекта, он перестает умещаться в одном разработчике. Как в плане количества используемых технологий, так и в плане временных рамок.
И вот в таком случае fullstack без проблем может стать его архитектором, нанимая, руководя и направляя специалистов в нужном русле. Хотя бы потому, что он имеет хорошее представление, как все это работает изнутри, а не отдавать на откуп весь проект команде, мол раз они спецы, значит сами знают, как лучше (из такого подхода часто получается лебедь рак и щука, и как итог — абсолютно несбалансированное приложение/проект, срывы сроков и т.п.). Сколотить команду не как «партнеры по интересам», а нанять конкретных специалистов, которые нужны для ликвидации узких мест в проекте. Направлять их именно туда, где они нужны, максимизировать производительность разработки.
На мой взгляд, это никак не коррелирует с термином «аникей».
rjhdby
20.11.2018 11:47Эникейщик — это человек, который умеет нажимать «Any key». Т.е. решать шаблонные задачи даже не задумываясь, что и почему происходит — «Попробуйте перезагрузить компьютер»
Любой системный администратор может с легкостью эмулировать работу эникейщика, поскольку тоже умеет решать эти шаблонные задачи, но, в отличии, он обычно понимает что и почему делает.
Если и дальше проводить аналогии между админством и разработкой, то fullstack — это админ универсал, который умеет в *nix, Windows, сетевое оборудование и телефонию. Именно умеет, а не просто потыркать кнопки по инструкции.
Он проиграет узко-специализированному админу Windows на его поле, но, зато, уделает его в сухую на поле *nix, сети… И т.д.
roscomtheend
20.11.2018 14:45Эникей не может в БД, не может в бэк, не может во фронт. По факту эникей может поставить систему со зверь-CD, поменять картридж да перекрутить пару плат, пропылесосить системник. Продвинутый может продиагностировать систему и найти неисправность, почистить не очень сложные вирусы. Изредка пару простейших скриптов написать может, но никогда не слышал чтобы эникеем называли кого-то, хоть отдалённо похожего на разработчика.
lega
20.11.2018 11:07примите как факт то, что вы всегда (всегда) будете уступать узкоспециализированным разработчикам во всем
Как сказал Бобук — не редко fullstack специалист вырастает, как раз, из узкоспециализированного, как результат fullstack = узкоспециализированный + смежные области. Поэтому он не будет уступать в своей «специализации».HerrDirektor Автор
20.11.2018 11:17Он почти всегда так вырастает. Но если изучать одновременно 5-10 технологий, вы в любом случае не сможете так же хорошо, как человек, который изучает и работает только в одной-двух. Просто не хватит времени.
Но поддерживать знания «исходной технологии» на приемлемом (т.е. если были условным «синьором», то ниже вряд ли опуститесь) уровне разумеется можно.
worldmind
20.11.2018 12:12Пока будет изучать смежные области деградирует в своей специализации, ведь чтобы стоять на месте нужно очень быстро бежать.
rjhdby
20.11.2018 11:29+1хитрый интроверт с силой воли
Как емко и точно — снимаю шляпу! *Прикопал для статусов в социалках
spmbt
20.11.2018 12:22Вы меня совсем запутали: один говорит — не беги, другой — беги. Куда бежать, что делать? Куда податься стройными рядами? Вот остановлюсь и вообще ничего делать не буду.
HerrDirektor Автор
20.11.2018 12:28Вот остановлюсь и вообще ничего делать не буду.
Я так пробовал. Хватило ненадолго, все равно обратно затянуло :)
Neikist
20.11.2018 12:30А правильный ответ, имхо, делать то что нравится. Не, если оценивать с точки зрения денег или востребованности — там можно обсуждать, но по факту если тянет на разные технологии — хорошо, хочется копать одну — прекрасно. Иначе на мой взгляд есть шанс потерять интерес если делать не то что нравится а то что выгодно.
sheshanaag
20.11.2018 16:56Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да?
Нет, так устроен мир.
difference
20.11.2018 17:28>Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да?
я такого не наблюдаю. Откуда такая информация?
фуллстэки возникают по разным причинам — у кого-то карьера была немного хаотичная что пришлось поработать на разных фронтах, а кто-то психологически тяготеет к разнообразию.
По-моему, самый серьёзный минус фуллстэка — это подпадание под определённый тип проектов. Поясню.
Например вы стаффите персонал на проект с какой-то крупной мастабируемой и отказоустойчивой системой для ритейла. На такой проект лучше стаффить хороших специалистов в какой-то области, но чтобы они знали её хорошо. Т.к. не очень актуально чтобы человек умел и фронтэнд и бэкэнд, потому что для этого есть отдельные команды, зато очень актуально чтобы человек разбирался в своей теме глубоко. Вряд ли будет умным стаффить фуллстэка и поставить его готовить DevOps с докером на AWS, попутно давая писать код на C# для микросервиса и ещё лабать формочки на js/html/css. В этом нет смысла, кроме если бюджеты съели, и надо нанять человека для счёта. Классный специалист — классный именно и какраз потому что знает много тонкостей, которые как хорошо говорят американцы, can make difference, т.к. если человек не понимает как работает MVCC в Oracle и будет думать что Serialized изоляция это последовательное выполнение транзакций — его ждёт фэйл и поиск бага возможно на часы. Эксперта от просто кодера отличает знание тысячи мелочей, точно так же как гонщика-звезду отличает от обычного доли секунды в реакции.
И тенденции что якобы всё больше людей нужны на фуллстэк, я, признаться, совсем не наблюдаю. Да, нередко хотят нанят человека который и «корова и бык, и баба и мужик», но я не думаю что есть смысл вестись на эту удочку.HerrDirektor Автор
20.11.2018 17:55По-моему, вы невнимательно прочли статью. В ней прямо в том самом месте, которое вы процитировали, написано:
Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да? Тем не менее, в подавляющем большинстве случаев, так оно и есть (если конечно мы хотим использовать фуллстек, как фуллстек, а не как «программиста Java»). Там, где много платят с первых дней/месяцев работы, обычно не требуется «и швец и жнец, и на дуде игрец» — там требуется еще одна хорошо смазанная шестеренка в общий механизм, которая будет делать ровно одну задачу, и делать ее хорошо, так, как сказал тимлид.
Вы же зачем-то приводите как раз тот случай, где фуллстек выполняет роль «шестеренки». Разумеется, для такой задачи (которую вы приводите) эффективней будет нанять узкого специалиста (команду разноплановых специалистов). Но даже в вашем случае фуллстеком вполне может быть тимлид/архитектор — человек, который понимает на приемлемом уровне во всех применяемых технологиях, способен разрабатывать/вести архитектуру проекта, а так же управлять разработчиками, поддерживая общий баланс проекта. Про это тоже написано.
И тенденции что якобы всё больше людей нужны на фуллстэк, я, признаться, совсем не наблюдаю.
Я про такое даже не упоминал.
LekaOleg
20.11.2018 19:47А с чего Вы взяли что full stack должен разбираться в DevOps? И не обязательно прыгать по языкам. Мне к примеру достаточно php и js как основных и далее я в них капаю как можно глубже, работа с разными фреймворками и тд. Насколько я понимаю это только фронтенд и бекенд, а админы это уже совсем другая история.
VolCh
21.11.2018 15:30Вряд ли будет умным стаффить фуллстэка и поставить его готовить DevOps с докером на AWS, попутно давая писать код на C# для микросервиса и ещё лабать формочки на js/html/css. В этом нет смысла, кроме если бюджеты съели, и надо нанять человека для счёта.
В этом есть смысл, например, если даже двух девопсов бюджет проекта не потянет, или просто выкидыванием денег, потому что даже одного на 100% не нагрузить, а резервирование нужно.
Или ещё проще, у вас классический скрам. Команда разработки, минимальный состав по специализациям:
- дизайнер (с хотя бы минимальным знанием верстки)
- бэкендер (Java/C#/PHP/JS… + SQL/NoSQL/...)
- фронтендер (JS+вёрстка)
- тестировщик (мануал+ авто)
- девопс (администрирование и немного разработки)
Уже 5 человек, причём почти каждый из них уже мини-фуллстэк и никакого резервирования, резервировать каждого — минимум 10 человек, что выше рекомендуемого максимума в 9 человек, ну пускай дизайнера не резервируем, можно какое-то время пожить без него — достигаем максимума. Но если задачи идут неравномерно хотя бы по спринтам, то сталкиваемся с недонагрузкой команды. Разве не будет оптимальным к 5 специалистам добавить хотя бы пару фуллстеков?
Baked_chicken
21.11.2018 10:01Был опыт разработки и мобильного приложения, и серверной/фронтовой части для него в другой команде. Как описать весь этот опыт в резюме и найти такую компанию, где это востребовано?
Alexeyslav
Прошло уже пол часа, и где срач? Обман, кругом обман… а может это заклинание такое эффективное?
HerrDirektor Автор
Видимо, сильное колдунство в этой фразе! Нужно бы записать, чтобы не забыть :)