Разновидности Full-stack разработчиков
Вариаций Full-stack разработчиков, на самом деле, множество: PHP Full-stack Developer, Node.js Full-stack Developer, Java Full-stack Developer и так далее. Название, которое стоит в самом начале специальности, говорит о том, какой язык/платформа берется за основу во время реализации BackEnd части. Стек технологий FrontEnd-а практически всегда одинаков и отличается лишь используемыми JavaScript-фреймворками — Angular, React или Vue.js. А вот бекенд предоставляет гораздо больше возможностей для реализации своих амбиций.
Еще раз проговорим, что Full-stack Developer — это разработчик, который принимает непосредственное участие во всех этапах разработки веб-приложений — от создания клиентской части (визуальная часть + пользовательская логика) до реализации серверной (базы данных, серверная архитектура, программная логика). Какой стек технологий и языков находится в распоряжении данного специалиста? Если говорить о FrontEnd составляющей (клиентская сторона), то она у всех примерно одинакова:
язык верстки HTML и язык стилей CSS;
языки программирования JavaScript и TypeScript;
препроцессоры SASS и LESS;
библиотека jQuery;
фреймворк Bootstrap;
фреймворк Angular/React/Vue.js;
технологии DOM, AJAX, JSON;
навыки адаптивной и кроссбраузерной верстки.
Теперь разберемся с ответвлениями в бекенде, которые указывают на популярные языки и технологии, использующиеся во время реализации серверной стороны разрабатываемых веб-приложений.
Node.js Full-stack Developer
BackEnd составляющая (серверная сторона) может иметь различную начинку, в отличии от FrontEnd. Если говорить о Node.js Full-stack разработчике, то в качестве основного языка выступает JavaScript, а сам стек следующий:
платформа Node.js;
фреймворк Express.js;
пакетные менеджеры npm, yarn;
Web Sockets;
понимание REST API;
другие специализированные технологии.
Java Full-stack Developer
Главный акцент делается на язык программирования Java и связанные с ним технологии. BackEnd-стек у такого разработчика должен быть следующим:
язык Java + Java Core;
веб-сервер Apache;
инструменты для комфортного взаимодействия с БД — JPA/Hibernate;
фреймворк Spring (Spring MVC, Spring Boot, Spring REST, Spring Web);
применение облачных сервисов Google Cloud, AWS или Azure;
знание сервлетов, JSP (Java Server Pages);
знание микросервисов.
ASP.NET Full-stack Developer
.NET разработчики имеют широкий инструментарий для самореализации в вебе. В качестве основного языка программирования они используют C#. Копилка знаний BackEnd части у ASP.NET Full-stack Developer-а должна содержать:
PHP — классический язык веб-разработки. Типичный BackEnd-стек данного разработчика отличается от остальных своей компактностью. РНР в вебе уже достаточно давно, а потому ему многого не нужно, а достаточно лишь:
собственно, сам язык PHP;
фреймворк Yii2/Symfony/Laravel.
Python Full-stack Developer
Универсальность Python не знает границ! Не стала исключением и сфера веб-разработки. BackEnd-стек Python Full-stack специалиста следующий:
язык Python;
фреймворк Django/Flask;
REST API;
Web Sockets;
навыки работы с ОС Linux и веб-сервером Nginx/Apache (возможно);
опыт работы с облачными сервисами.
Также, помимо специализированных технологий, всем Full-stack разработчикам необходимо:
знать систему управления версиями Git + сервис для хостинга IT-проектов GitHub;
знать реляционные (SQL) и нереляционные (NoSQL) базы данных, уметь их проектировать;
разбираться в протоколах HTTP, HTTPS;
уметь оперировать языком запросов SQL и одной из СУБД — MySQL / PostgreSQL / SQLServer, либо одной из NoSQL СУБД (MongoDB, например);
уметь проводить тестирование приложений;
осуществлять Code Review;
использовать Docker;
владеть английским языком на уровне Intermediate и выше;
знать популярные паттерны программирования и уметь их реализовывать;
иметь хорошее знание алгоритмов и структур данных.
Также, от Full-stack специалиста могут потребовать навыки мобильной разработки, если работодатель будет намерен портировать веб-приложение на соответствующие платформы.
Как видите, список необходимых языков и технологий для создания хорошей серверной составляющей веб-приложений достаточно внушительный. В следующей главе мы разберемся, какие преимущества и недостатки подстерегают тех, кто таки намерился связать свою профессиональную деятельность с Full-stack разработкой.
Перевод: Кто такой Full Stack разработчик?
Привет, Хабр! Представляю вашему вниманию перевод статьи «What is a Full Stack developer?» автора Laurence Gellert.
Кто такой Full Stack разработчик?
Разумно ли ожидать, что простые смертные будут владеть всеми аспектами разработки? Скорее всего нет, но в Facebook могут попросить об этом. На OSCON (O’Reilly Open Source Convention — ежегодный съезд, посвящённый обсуждению открытому и свободному программному обеспечению) один из сотрудников Facebook сказал, что они нанимают только Full Stack разработчиков. Что это значит?
Для меня Full Stack разработчик — это человек с хорошим пониманием каждого уровня разработки и искренне интересующийся всеми программными технологиями.
Хорошие разработчики, знакомые со всем стеком, знают, как облегчить жизнь тем, кто их окружает. Вот почему я так против разрозненности на рабочем месте. Конечно, политические и коммуникационные проблемы мешают в больших организациях. Я думаю суть политики найма в Facebook заключается в том, что если умные люди используют свои головы и слушаются своего сердца, то лучший продукт создается за меньшее время.
Уровни Full Stack разработки:
Сервер, сеть и среда хостинга
A. Это включает в себя понимание того, что может сломаться и почему, не принимая никаких ресурсов как должное.
B. Необходимо надлежащее использование файловой системы, облачного хранилища, сетевых ресурсов, а также понимание избыточности и доступности данных.
C. Как приложение масштабируется с учетом аппаратных ограничений?
D. Как насчет многопоточности и состояния гонки? Скорее всего вы не примените их в своей разработке, но они используются в мире.
E. Full stack разработчики могут работать бок о бок с DevOps. Системы должна представлять полезные сообщения об ошибках и возможность логирования.
Моделирование данных
A. Если модель данных несовершенна, бизнес логике и более высокие уровни начинают нуждаться в странном (уродливом) коде, чтобы компенсировать случаи, которые модель данных не охватывает.
B. Full stack разработчики знают, как создать разумно нормализированную реляционную модель, дополненную внешними ключами, индексами, представлениями, таблицами поиска и т.д.
С. Full stack разработчики знакомы с концепцией нереляционных баз данных и понимают в чем они превосходят реляционные базы данных.
Бизнес логика
A. Понимание ценности, которую представляет приложение.
B. Знание твердых объектно-ориентированные принципов.
С. Знание фреймворков, которые могут использоваться.
Уровень API / Уровень действий / MVC
A. Как внешний мир влияет на бизнес логику и модель данных.
B. Фреймворки должны активно использоваться на этом уровне.
С. Full stack разработчики имеют способность писать четкие, последовательные, простые в использовании интерфейсы. Меня отталкивает степень запутанности некоторых API.
Пользовательский интерфейс (UI)
A. Full stack разработчики: а) понимают, как сделать читаемый макет, или b) признают, что им нужна помощь художников и графических дизайнеров. В любом случае, реализация хорошего визуального дизайна является ключевым моментом.
B. Владение HTML5 / CSS.
С. JavaScript это перспективный язык будущего и в мире JavaScript делается много захватывающих проектов (node, backbone, knockout. ).
Пользовательский опыт (UX)
A. Full stack разработчики ценят, что пользователи просто хотят, чтобы всё работало.
B. Хорошая система не дает своим пользователям синдром запястного канала или воспаления глаз.
С. Full stack разработчики пишут читаемые сообщения об ошибках. Если что-то сломалось, извинитесь за это. Иногда программисты непреднамеренно пишут сообщения об ошибках, читая которые пользователь чувствует себя глупым.
Понимание что нужно клиенту и бизнесу
A. Сейчас мы размываем черту архитектора, но это слишком большая роль.
B. Full stack разработчики имеют представление о том, что происходит, когда пользователь использует программное обеспечение. Они также имеют представление о бизнесе.
Другие важные моменты
Заключительные мысли
Очень плохая практика — жестко привязывать код к конкретной реализации (библиотека, ОС, аппаратное обеспечение и т.д.). Тот факт, что full stack разработчик понимает весь спектр технологий, не означает, что у него есть разрешение на использование самого простого пути. На самом деле они делают это, если это «проект на выброс».
Технологические стартапы нуждаются в full stack разработчиках из-за их универсальности! Однако, по мере развития организации, ей требуется всё больше и больше целенаправленных специалистов.
Я не уверен, что вы можете называть себя full stack разработчиком пока вы не поработаете на нескольких языках, платформах и даже отраслях в своей профессиональной карьере. Full stack выходит за рамки «senior engineer», поскольку он находится в том же направлении, что и программист-полиглот, но с более высоким представлением всех соединительных частей. Обратите внимание, что в моем списке только 3-5 пунктов, связанных с написанием кода.
Чем плохо быть full stack разработчиком
Минусы
В каждой отдельной области вы хуже, чем узкий специалист
Кажется довольно очевидным, но всё же поясню. Если вы потратили шесть лет на одну технологию, то с очевидностью ваши знания будут больше, чем у человека, который шесть лет занимался несколькими. У вас было больше проектов, вы больше занимались какими-то типичными решениями, больше читали и писали код.
Вам сложнее продвигаться глубже
Хороший full stack разработчик всегда сильно нагружен. И ваше время на познание нового распределяется между всеми технологиями, с которыми вы работаете. Естественно, что ваше развитие происходит медленнее, чем у программиста узкой специализации.
У вас больше вероятность перегрузки задачами
Если вы занимаетесь сразу несколькими проектами с нескольких сторон, то даже при хорошем тайм менеджменте часто будет случаться так, что все проекты требуют к себе повышенного внимания и времени. Придётся это решать или передачей части задач другим разработчикам, или распределением приоритетов, или тщательным планированием. Конечно, вероятность перегрузки есть у любого разработчика — как известно, в реальном мире любую задачу нужно делать “вчера”. Но у вас такие задачи могут внезапно появляться пачками.
Вас сложно заменить
Кому-то это может показаться плюсом — вас сложно уволить, вас любят и ценят. Но обратная сторона медали — невозможность передачи задач, звонки в любое время суток, проблемы с уходом в отпуск, сложности при попытке заняться чем-то другим.
У вас нет чёткой зоны ответственности
Если в кране нет воды — значит, виноват full stack! Какие бы проблемы не возникали, какие бы баги не вылезали — скорее всего, именно вам придётся ими заниматься, даже если проблема на самом деле должна быть в ведении другого разработчика. Просто ваша картина мира гораздо полнее, и вы быстрее сможете локализовать и исправить ошибку. К сожалению, этим часто злоупотребляют.
“О, дайте ему — он разберётся!”
В ситуации, когда необходимо разобраться с плохим или старым кодом, скорее всего задействуют именно вас. Особенно печально, когда работодатель хочет сэкономить, наняв одного разработчика на весь проект. А ты его открываешь и понимаешь, что проще это выкинуть и целиком переписать.
Вы не знаете всех наборов библиотек
Это довольно очевидно следует из первого пункта, но хочется упомянуть отдельно — хотя бы потому, что в вакансиях часто требуется опыт работы с конкретными библиотеками.
Вы не успеваете за всеми тенденциями
Опять же это следует из первого пункта. По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад. Увы, вы не можете одновременно знать и уметь применять ES6, рассказать об отличиях последней версии Symfony и о возможных проблемах миграции с Oracle на Tibero в текущий момент. Возможно, вы об этом читали, но попробовать просто не успели.
Вы не всегда пишете оптимальный код
Скорее всего, ваш код понятен, хорошо систематизирован и откомментирован. Но наверняка более квалифицированный специалист мог бы сделать его чуть лучше. Другой вопрос, что это обычно не критично. Действительно плохо, если каша из языков в голове заставляет вас применять подходы и решения, которые никак не годятся в текущем проекте. Ужасно видеть, как некоторые даже пишут функции, которые были бы созвучны привычным для них реализациям в другом языке.
Вы часто подглядываете в мануалы
Даже функции для работы со строками во всех языках выглядят по разному, что уж говорить о чём-то более сложном. Если вы часто переключаетесь между разными технологиями и языками, то скорее всего у вас непрерывно будет висеть мануал, в который вы подглядываете, что конечно несколько снижает скорость работы.
Вы можете начать завидовать зарплате узких специалистов
Если начать искать вакансии по самому вашему дорогому навыку, то можно огорчиться — специалисты с большим опытом работы могут получать за него весьма неплохие деньги. Скажем честно — у вас такого опыта работы с конкретной технологией нет. Но даже если вы углубитесь в эту технологию и получите необходимые знания — хотели бы вы дальше всю жизнь заниматься только этим? Например, администрированием СУБД Oracle?
Минусы в трудоустройстве
Отдельно хочется упомянуть сложности, которые случаются при смене работы.
Вас буду звать работать по случайным ключевым словам в резюме
HR не всматривается в то, что указанной технологией вы занимались на небольшом проекте три года назад. Он увидел слово, похожее на вакансию, которую надо закрыть, сделал стойку, и пытается вас туда пристроить любой ценой, не интересуясь вашими желаниями и текущими предпочтениями.
Full stack full stack’у рознь
Какой бы вы ни были широкий специалист, вряд ли вы найдёте место работы с точно таким же стеком технологий. Бывает, но крайне редко. Однако пересечения часто довольно большие, и ничто не мешает вам подтянуть недостающее и ещё больше расширить кругозор.
Вам не верят
Да, вот такая смешная и реальная проблема. Если вы указали в резюме слишком много всего, то вам просто не поверят и даже не будут пытаться проверять или спрашивать о том, на каком уровне вы что знаете. Поэтому, как ни смешно, лучший способ — безжалостно удалять из резюме все сведения, которые вы считаете неактульными для своего будущего. А ещё лучше — подгонять резюме под каждую вакансию.
Вам сложнее искать подходящую вакансию
Fullstack разработчиков ищут довольно редко, и не всегда работодатель с такой вакансией может конкурировать с вакансией узкой специализации по условиям. И возникает вопрос — какие использовать ключевые слова при поиске вакансии? Если вы, скажем, Java разработчик, то просто указали в поиске Java — и погнали кликать. Но full stack’у немного сложнее. Обычно проблема решается подпиской на несколько разных фильтров по словам, которые вам наиболее интересны — или просто выборкой по желаемому уровню зарплаты. Последнее не всегда срабатывает, поскольку к моему величайшему недоумению до сих пор висит огромное количество вакансий вообще без указаний зарплатной вилки. Видимо, HR боятся, что тогда каждый захочет описанный максимум? Странно. Если кто знает доводы в пользу такой стратегии рекрутинга — приведите, пожалуйста, в комментариях.
Плюсы
Теперь, наконец, о вкусном.
Вы можете выбирать, кем работать дальше
Вам гораздо проще сменить ориентацию (простите за двусмысленность), чем обычному разработчику. Вы видите многое в применении, можете разобраться и понять, что вас интересует. Да, вам придётся потратить время на углубление — но это будет потраченное с пользой время. Да, вам скорее всего придётся завести несколько пет проджектов, чтобы попробовать всё, что хочется. Но это опять же окупается сторицей.
Вы меньше выгораете
Если есть возможность периодически менять проекты, то вы гораздо меньше устаёте от применения одного и того же. Конечно, если вы не хардкорный фанат и не получаете удовольствие просто от того, что пишете всё, скажем, на vanilla C или asm.
Вам проще расти в тимлида или архитектора
Довольно очевидный плюс — чем больше вы разбираетесь в общей структуре, тем больше у вас шансов на рост в руководителя. Конечно, при наличии желания и коммуникативных навыков.
Вы можете отдебажить всё, что угодно
Очевидный плюс. Ваше системное мышление достигло уровня, на котором вы можете исправить что угодно и где угодно.
Работать веселее, интереснее и познавательнее
За один день вы можете получить много новых навыков и знаний в абсолютно разных вещах.
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
Вы один можете сделать то, на что при стандартном подходе требуется 3-4 человека. Запрограммировать микроконтроллер для интернета вещей, который общается с веб сервером, пишет в базу данных, и данные с которого можно просматривать на веб сайте, в приложении или на мобильном устройстве? Легко! Вы один можете представить всю систему и реализовать её без согласований, недопониманий и проволочек.
Ваши решения работают быстрее и надёжнее
За счёт понимания взаимодействия различных систем, вы можете выбрать лучше пути для их комбинирования. Вы лучше понимаете каждый компонент и не боитесь его использовать. Как пример — возьмём “кляудные технологии” (мопед не мой, в публикациях проскакивало). В общем и целом, облако это чудесный способ решения огромного количества задач, в том числе задач масштабирования. К сожалению, всё чаще вижу, что облачные решения используются просто потому, что разработчик не умеет и боится решить свою задачу как-то ещё, а представляет это в виде дополнительного плюса. А многое можно сделать гораздо дешевле и лучше, если иметь хотя бы поверхностное понимание вопроса.
Вы можете пользоваться почти любыми исходниками
В мире, где решена уже практическая любая прикладная задача, тратить время на то, чтобы написать ещё один велосипед — просто преступление по отношению к длительности своей жизни. Теперь вы можете взять любой репозиторий на любом языке и воспользоваться им как отправной точкой для своего решения. Вы пролетите свежим бризом над граблями, которые до вас собрали тысячи других разработчиков.
Вы постигаете дзен
Теперь вы знаете, что нет языка разработки, которых лучше остальных. Вы знаете, что нет самой лучшей базы данных. Вы можете предположить, что какой-то инструмент подходит для ваших целей лучше… но вы вполне готовы использовать альтернативы, если на то есть какие-то основания, например, квалификация остальных разработчиков. Вы больше не пишете статей про синтетические тесты, созданные с тем, чтобы показать преимущества одной технологии над другой. Вы знаете, что прирост производительности в пять процентов скорее всего не стоит двух ваших человеко-месяцев. А освободившееся от холиваров время вы наконец можете потратить на что-то полезное. Например, чтобы наладить взаимоотношения с девушкой (для примера назовём её Катей). Вы теперь понимаете, что технологии бывают разные, что люди бывают разные, и нужно просто найти правильный способ связать всё воедино. Ты любишь мир, и мир любит тебя. Даже когда ты его используешь, чтобы выстрелить себе в ногу.
Здесь должна была быть картинка, на которой показано, как просветлённый программист в позе Лотоса медленно возносится над горами Тибета, а вокруг него танцуют, обнимаются и водят хоровод языки программирования и различные технологии в образе очаровательных девушек — но увы, такой картинки почему-то не нашёл. Пожалуйста, представьте это сами.
Меняю свой стек с понедельника
Примерно за год до момента написания этой статьи мне начало казаться, что я начал выгорать. Работа, уже давно превратившаяся в ремесло, перестала приносить то студенческое чувство первооткрытия, знакомое каждому программисту, приносящее эйфорию. Ради этого чувства, ради новых знаний я когда-то просиживал за монитором по 18 часов в сутки. Это давно прошло… но недавно я испытал это чувство снова! Сначала оно было тихим, непривычным из-за длительного перерыва, но со временем оно разгорелось и заполыхало!
Как было указано до ката, мне показалось, что я выгораю. Когда нам принесли новый проект для реализации (не слишком большой — это важно!), уже на первом совещании я знал, что и как именно мы будем делать — скукота.
Вы себя ещё не узнали? Если вы моложе, обязательно продолжайте читать, у вас всё впереди. Если вы ушли дальше меня, продолжайте читать, а в комментариях расскажите о своем опыте.
Итак, впереди у меня маячило примерно пол года неинтересной работы. Но мы сдали проект на несколько месяцев раньше, узнали кучу крутейших вещей, прокачались в смежных областях и получили массу удовольствия! Не буду долго тянуть… новый проект был сделан на полностью новом стеке: Node.js + React.
Оговорим правила
Проекты с привлечением до 3-5 программистов
Отсутствие существенных вычислений и сложной логики в backend
Использовать JavaScript (или даже TypeScript, вас это не спасет), язык с динамической типизацией без многопоточности и без Linq, для реализации вычислений или более-менее сложной бизнес-логики, просто нельзя — язык просто для этого не предназначен. Чего не скажешь про C#. Важно учитывать специфику инструмента, чтобы не забивать гвозди микроскопом.
Наличие возможности и/или необходимости унифицировать backend и frontend
Унификация поможет снизить порог входа, бюджеты и сроки. Но у палки всегда есть два конца и необдуманный шаг со стороны «эффективных менеджеров» без реальной необходимости может привести к потерям.
Принимая во внимание перечисленные ограничения, предлагаю следующий чек-лист, пройдясь по которому вы сможете оценить применимость к вашей экосистеме проектов.
Чек-лист
Стоимость разработки и содержания
Требует ли ваш бюджет низкого порога входа специалистов и невысокой стоимости содержания?
Запуск MVP (minimum viable product) и PoC (proof of concept)
Горят ли ваши сроки для запуска MVP или PoC?
Среда разработки
Будет ли вам достаточно функциональности «легких» IDE?
Для Node.js в связке с React отлично подходят «легковесные» IDE. Например, VS Code — не требует больших мощностей при разработке, кроссплатформенный редактор, распространяется бесплатно, его функциональности вполне хватает, чтобы комфортно разрабатывать как backend, так и frontend.
Для проектов на C# можно использовать Visual Studio Community — тоже условно-бесплатную IDE, но она уже потребует ресурсов, будет не такой шустрой и не кроссплатформенной.
Типизация языка
Вы сможете обеспечить качественную разработку и поддержку своего проекта, учитывая отсутствие типизации?
Отсутствие типизации в языке — это палка о двух концах. С одной стороны, такой подход позволяет кратно увеличить скорость разработки, уменьшив объем кода. С другой стороны, кратно увеличивается объем тестирования. Кроме того, некоторые ошибки могут проявиться только во время эксплуатации, успешно преодолев все тесты. Крупные проекты делать без типизации становится затруднительно.
Производительность и масштабирование
Вы готовы отказаться от полноценной многопоточности из коробки? В вашем проекте отсутствуют сложные вычисления или бизнес-логика?
Как известно, в Node.js реализовано однопоточная событийно-ориентированная модель. Это отлично подходит для большого количества запросов, но совершенно не годится для распараллеливания вычислений или реализации сложной бизнес-логики. Таким образом, при выборе стека для backend’а на Node.js, надо отдавать себе отчет о нюансах его работы.
Кроссплатформенность
Вам требуется кроссплатформенность из коробки?