Хабрахабр

[Из песочницы] Fullstack – почему это клево, или как получать от работы удовольствие

Недавно на Хабре разгорелись нешуточные баталии в комментариях к заметке Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

Я попробую высказать свою точку зрения о том, что фуллстек – это на самом деле клево, и почему по этому пути идти хорошо.

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

**АХТУНГ! Все нижесказанное не является абсолютной истиной в последней инстанции и является моим субъективным видением (этого мира).

Для начала давайте определимся с терминами, о которых пойдет речь ниже, чтобы быть в одном информационном поле, т.к. понятие fullstack у всех разное (ровно как и разделение на Junior/Middle/Senior и прочие табели о рангах).

Наиболее часто встречается мнение, что fullstack – это разработчик, который в одно лицо может работать над проектом полностью своими силами, от бэка до фронта.

Если разработчик фронта может что-то исправить/добавить в коде бэка, поковыряться в запросах БД, это еще совсем не фуллстек.
Ведь разработка проекта – это не только код бэка и фронта, это еще и постройка/настройка/поддержка инфраструктуры для получившегося продукта. Некоторые из вас могут сказать «ну такое у меня в команде мидлы могут», что (мягко говоря) в большинстве случаев неверно. А объектом может быть и 5-долларовая VPS с LAMP в дефолте, и облачные сети типа AWS/Azure, или вообще собственная инфраструктура, где живет вполне себе реальное железо, от серверов/рабочих станций до маршрутизаторов. Мало написать код, его еще нужно заставить работать на объекте.

Который может тянуть в одно лицо проект от стадии переговоров, до стадии подписания акта о выполненных работах. Поэтому речь пойдет не совсем о «fullstack-dev», а скорее о «fullstack-вообще».

это крайне расплывчатый список. Я не буду загибать пальцы, перечисляя, что должен, а чего не должен знать fullstack-специалист, т.к. В конце концов, кто-то умудряется сдавать и продвигать «проекты одного инструмента», скажем на Java с NoSQL, но сегодня мы про такое не будем.

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

Кратко пробежимся по плюсминусам, лежащим на поверхности.

Минусы

Вероятно, самый очевидный минус — примите как факт то, что вы всегда (всегда) будете уступать узкоспециализированным разработчикам во всем – от владения самыми современными тулами и технологиями, до качества кода. Если вы амбициозны, хотите всегда быть на острие прогресса, хотите гнуть пальцы и смотреть на остальных, как на говно – fullstack не ваш путь.

Но найти высокооплачиваемую работу все же сложнее. Найти работу для 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.

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

Соизмеряйте инструменты и задачи. Совет седьмой. Не нужно разворачивать локальную инфраструктуру с блэкджеком и девицами с низкой социальной ответственностью для одностраничного «корпоративного сайта», просто потому. Не стоит палить из пушки по воробьям. И тащить на этот сайт 5Мб JS-фреймворков тоже не нужно (только потому, что вы в них можете). что вы можете это настроить.

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

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

Пожалуй для начала этого хватит. Уф.

Всем спасибо за внимание.

Ах да, чуть не забыл… Да начнется срач!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть