Fullstack что такое

Кто такой Fullstack-разработчик?

Fullstack-разработчик — универсальный солдат, который может самостоятельно реализовать проект ‎«под ключ», охватив и backend, и frontend. Вместе с fullstack-разработчиком и ментором SkillFactory Олегом Ледвановым отвечаем на главные вопросы о профессии и разбираемся, благодаря чему fullstack’и могут работать удаленно и всегда получать много заказов.

Что делает fullstack-разработчик?

Fullstack-разработчик выполняет веб-разработку полного цикла. Обычно он создает веб-приложения, в которых занимается сразу всем: проектирует архитектуру, разрабатывает frontend- (то, как сайт или приложение видят пользователи) и backend-части ( все, что помогает сайту или приложению работать), привязывает проект к базе данных, обновляет его и занимается системным администрированием.

Где он нужен?

Fullstack-разработчики востребованы во всех сферах бизнеса. В крупных компаниях они часто занимаются небольшими продуктами, например для внутренней оптимизации. Но могут и руководить командой программистов, так как понимают особенности разных типов разработки. Много fullstack-разработчиков работают на фрилансе, потому что могут решить главную задачу малого бизнеса – быстро разработать сайт с минимальными затратами.

Пример задачи

Если fullstack-разработчику нужно создать интернет-магазин, то он:

Что ему нужно знать?

Такой разработчик должен знать один или несколько языков программирования. Для frontend-разработки используют JavaScript и фреймворки (готовые «‎каркасы»‎ программы, на основе которых можно разрабатывать продукт) React, Angular или VueJS. Для backend-разработки — Python с фреймворками Django, Flask или Sanic, JavaScript с фреймворками Express или Fastify, PHP и фреймворк Laravel. Помимо этого, нужно знать язык SQL, язык разметки CSS, системы контейнеризации Docker и Git, основы системного администрирования. Важно владеть английским языком, поскольку документация обычно написана на нем.

Научитесь программировать на Python и JavaScript и станьте универсальным солдатом веб-разработки. Вот вам еще 5% скидки по промокоду BLOG.

Как выглядит его рабочий день?

В течение рабочего дня fullstack-разработчики пишут код, общаются с командой или обсуждают технические задания с заказчиками. Помимо этого, fullstack-разработчик должен быть в курсе последних новостей в своих областях, поэтому ему нужно участвовать в конференциях (например DevConf или BackendConf) и читать полезные ресурсы (например CodeProject или Stack Overflow).

Как строят карьеру fullstack-разработчики?

Традиционное деление на джуниор-, мидл- и синьор-разработчиков нечасто встречается среди fullstack-разработчиков. Обычно их делят на простых разработчиков и экспертов.

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

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

Какие нужны софт-скиллы?

Насколько это востребовано?

Согласно сервису «Яндекс.Подбор слов», люди ищут информацию по запросу «fullstack» каждые 7 минут. А в марте 2021 года на сайте hh.ru было около 1,5 тыс. вакансий fullstack-разработчика.

Сколько получает fullstack-разработчик?

Зарплата зависит от компании и навыков программиста. В среднем начинающие разработчики в Москве получают от 60 тыс. руб. в месяц, продвинутые профессионалы — до 300 тыс. руб. в месяц. На сайте hh.ru можно найти вакансии с зарплатой более 400 тыс. руб. в месяц.

Плюсы профессии

Минусы профессии

В каких случаях становятся fullstack-разработчиками?

Как начать?

Можно самостоятельно изучать видео, книги (например «Изучаем Python» Марка Лутца), сайты. Важно погрузиться в контекст, ходить на конференции и вебинары, приобретать первый опыт. А можно выбрать курсы с готовой программой обучения и поддержкой менторов. Начать учиться можно в любом возрасте и независимо от того, какой у вас бэкграунд.

Вы сможете браться за фриланс заказы и откликаться на вакансии уровня junior уже во время учебы. Карьерный центр поможет в трудоустройстве.

Источник

Fullstack-разработчик – кто это такой, достоинства и недостатки профессии и сколько можно заработать

О чем мечтает любой заказчик? Чтобы работник все выполнил быстро, качественно и желательно в одиночку, чтобы платить надо было меньше. Такой универсальный солдат – это миф, скажете вы?

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

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

Кто такой fullstack-разработчик

Fullstack-developer или фулстек-разработчик – это человек, который возлагает на себя ответственность за все этапы разработки веб-сервиса.

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

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

Фулстек-специалист нужен компаниям, когда заказчик хочет минимизировать недопонимания и сэкономить время или деньги.

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

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

Чем он занимается

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

В задачи fullstack-специалиста может входить:

Должность фулстек-программиста во многом схожа с профессией проект-менеджера. О ней вы можете прочитать в отдельной статье на блоге.

Связь с frontend и backend-разработчиками

Frontend-разработка – это создание того, что пользователь видит на веб-ресурсе. Визуальная часть создается при помощи HTML, CSS и JavaScript.

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

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

10–15 лет назад не было разделения на бэкенд и фронтенд-части. И разработчики по умолчанию числились как фулстек-программисты. Да и определения этой деятельности не было, как и самого слова “fullstack-разработчик”.

Разновидности fullstack-разработчиков

Фулстек-программисты делятся на категории в соответствии с тем языком программирования или платформой, с которой работают. Например, есть PHP-fullstack-developer или Java-fullstack-developer и так далее.

Фронтенд-часть у них во многом схожа. Они работают с:

Различия видов fullstack-разработчиков видны на уровне бэкенд-программирования.

Node.js-fullstack-разработчик. Использует в работе:

Java-фулстек-developer. Работает на основе следующих технологий:

ASP.NET-фулстек-программист. Эти разработчики используют в качестве инструментария:

PHP-fullstack-developer. PHP-разработчику достаточно владеть:

Python-фулстек-разработчик. Программист работает с:

Есть же категории fullstack-разработчиков, которые не связаны с языками программирования. Например, фулстек-дизайнер.

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

Должностные обязанности и личные качества

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

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

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

Плюсы и минусы профессии

К достоинствам работы относится:

Минусов тоже немало:

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

В России зарплата fullstack-разработчика находится примерно на том же уровне, что и у бэкенд-программистов: в среднем от 50 до 200 тыс. руб.

Стажер может рассчитывать на заработную плату от 30 000 руб. С опытом работы от 1 года – 50–100 тыс. руб. Зарплата от 150 000 руб. доступна разработчикам с 3-летним стажем и более.

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

Зарабатывать можно не только в российских компаниях. Зарубежные бизнесмены тоже ищут fullstack-разработчиков, и заработные платы в иностранных фирмах выше. Найти вакансии можно на международных биржах фриланса.

Как стать fullstack-разработчиком

Практически все фулстек-специалисты – бывшие бэкенд-программисты. Они во время разработки веб-ресурса сталкивались с задачами фронтенд-разработчика и постепенно переняли их знания.

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

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

Одна из распространенных ошибок новичков – они быстро вырастают “в ширину”, игнорируя “глубину”. В конце концов знаний получается очень много, но они все поверхностные и, по сути, эти программисты не могут делать свою работу достаточно хорошо.

Самый быстрый и легкий способ стать профессионалом – это записаться на онлайн-курсы.

Где обучиться с нуля

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

Я же предлагаю выбрать курсы с преподавателями-практиками.

Платформы “Нетология”, SkillFactory, itProger, Skillbox, SF Education и Udemy предлагают отличные онлайн-курсы по профессии fullstack-программист:

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

Где найти работу

Новичкам советую отправить резюме в небольшие IT-компании. Сначала придется побыть стажером, особенно если вы еще проходите обучение, а потом уже можно двигаться дальше.

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

Вакансии выложены на биржах фриланса, таких как:

Работу найти еще можно на профильных IT-сайтах или на всем известном hh.ru.

Со знаниями фулстек-программиста возможен еще один вариант заработка – открыть собственную компанию.

Заключение

Fullstack-разработчик – это тот человек, кто найдет себе работу вне зависимости от кризисов. Он делает работу сразу за двоих: за фронтенд и бэкенд-разработчиков.

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

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

Так что подавайте заявки, начинайте изучать аспекты новой деятельности или ищите на блоге iklife.ru статьи про другие удаленные профессии. Всего доброго, до встречи.

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

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

Источник

Перевод: Кто такой 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 разработчиком

Традиционно разработчики делятся на frontend и backend разработчиков; это обусловлено разделением ответственности между внешним представлением проекта (frontend) и внутренними технологиями (backend). Очень грубо обобщая, можно сказать, что фронтенд разрабатывает интерфейс, который видят пользователи, а бэкенд делает «начинку», т.е. программно-аппаратную часть. Такое деление является логичным и создано для упрощения разработки проекта. Однако все чаще в IT-среде появляются full-stack разработчики. О том, кто они такие и какие технологии актуальны для фулстек-разработчика, я расскажу ниже.

Определение

Full-stack developer (или фулстек-разработчик) – это разработчик, который должен разбираться во всем стеке технологий и используемых в проекте компонентов, как в части фронтенда, так и бэкенда. При этом такому разработчику совсем не обязательно быть senior во всех технологиях, которые используются при разработке приложения.

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

Фулстек разработчик имеет свои планы и минусы.

Плюсы :

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

HTML/CSS

HTML и CSS – основа основ. Любой веб-разработчик должен знать HTML и CSS. HTML позволяет добавлять контент на сайт, а CSS отвечает за стиль этого контента. Темы, которые чаще всего затрагиваются при разговоре о HTML/CSS во время собеседования:

JavaScript

JavaScript (JS) – язык, который с каждым годом становится все популярнее и обрастает все большим количеством библиотек, фреймворков и инструментов.

Интересно, что в опросе Stack Overflow 2016 года JS стал самым популярным языком во всех трех областях: fullstack, frontend и backend. В опросе 2017 года JS просто стал самым популярным языком среди всех языков программирования. Ничего удивительного в этом нет – JS единственный язык программирования, который используется и в браузере, и в качестве серверного языка (благодаря Node.js). В качестве фулстек-разработчика нужно разбираться в следующих темах:

Язык бэкенда

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

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

Базы данных и веб-хранилища

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

Поэтому обязательно нужно углубиться в следующие темы, касающиеся БД и хранения данных:

HTTP и REST

HTTP – это протокол передачи данных прикладного уровня, он обеспечивает взаимодействие сети и пользователя. Например, если JS-код делает какой-либо AJAX-запрос к бэкенду на сервере, то это происходит посредством HTTP. Важные в этой части темы перечислены ниже:

Архитектура веб-приложения

После того как вы познакомитесь с HTML/CSS, JavaScript, бэкендом, базами данных, а также HTTP/REST, настанет время перейти к архитектуре веб-приложения. Для того чтобы создать сложное приложение, вам нужно знать, как правильно структурировать код, как разделять файлы, где держать большие медиафайлы, как структурировать данные в базе данных и так далее.

Конечно, обо всем этом можно прочитать в сети, однако наилучшим решением будет практика, ведь лучше всего работать не одному, а в команде.

Поэтому не факт, что человек, который занимается разработкой более 7 лет, знает CSS или JS лучше разработчика с двухлетним опытом работы. Однако чем больше опыт у специалиста, тем с большим количеством приложений он работал, а значит, работая с ним в команде, появляется возможность узнать больше об архитектуре и дизайне приложений (помимо других важных вещей). Опыт дает возможность увидеть картинку целиком.

Однако пока вы в начале пути, ознакомьтесь со следующими темами:

А вот вам одно познавательное видео (на английском):

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

Заключение

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

Источник

Что вообще значит «full stack»?

Не счесть холиваров о том, стоит ли быть фуллстек-разработчиком. И в них часто вылезает ещё один спорный вопрос: а что это понятие означает-то? «Фронтбэкендер»? «Многорукий Шива, мастер всего от инфраструктуры до тестирования»? «Человек, освоивший столько технологий, что воспарил над ними в мир общих концепций»?

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

Когда понятие возникло? Как можно увидеть по графику Google Trends, в широкий обиход оно вошло с 2014-го. А на Хабре первое упоминание произошло в 2013-м. Это был перевод англоязычного блог-поста, где упоминается, что Facebook «нанимает только Full Stack». То есть в Фейсбуке это уже тогда было устоявшимся понятием? Я стал гуглить дальше и в техническом блоге Facebook нашёл пост 2010 года «The Full Stack, Part I» с тысячей лайков. А он, в свою очередь, ссылается на пост разработчика Рэнди Шмидта 2008 года. И, судя по прочей найденной мной информации, вот у Шмидта и было первое использование понятия, из которого выросло всё остальное. Теперь, когда мы добрались до начала начал, давайте пойдём по этим же постам в обратном направлении (по хронологии) и посмотрим, что в них говорилось.

2008: «Full Stack Web Developers» (Randy Schmidt)

Эта страница личного блога уже даже не открывается, но Internet Archive заботливо сохранил для нас Самый Первый Пост. Автор поста восхищается людьми, которых он называет «Full Stack Web Developers». И вот какое определение им он даёт:

A full stack web developer is someone that does design, markup, styling, behavior, and programming.

Вот это сейчас внезапно было: первым пунктом идёт дизайн. Д И З А Й Н. (Судя по контексту, слово design тут не в значении «проектирование», а именно как графический дизайн.) А «programming» упомянуто мимоходом как единый последний пункт — хотя сегодня обсуждения строятся как раз на том, что у него есть подпункты.

Ну, с programming понятно: в 2008-м ещё не произошёл JS-взрыв, поэтому в тексте «браузерная» часть проходит как «markup, styling» (читай: HTML, CSS). Но даже если мысленно заменить слова «markup, styling» и «programming» на «фронт» и «бэк», всё равно не получится нынешних дискуссий: это разделение Шмидта как раз не сильно волновало. По-настоящему его волновало, что он не разбирается в дизайне, и ему надо вот с этим справиться, чтобы стать настоящим full stack web developer. Так что получается, что мы сейчас под «фуллстеком» понимаем вообще не то, что закладывал автор.

По сути, содержание его поста сегодня в какой-то степени актуально внутри фронтенда, где есть место и JS-программированию, и более дизайнерским вещам. Так что, оставаясь в пределах фронтенда, можно специализироваться на чём-то, а можно быть многостаночником — в прошлом году нашумел текст «The Great Divide», посвящённый как раз этой разнице специализаций.

2010: «The Full Stack, Part I» (Carlos Bueno)

Следующие два года слова «full stack» не получали большого распространения, но затем Карлос Буэно из Фейсбука написал текст с таким заголовком, ссылающийся на Рэнди Шмидта. Поскольку у инженерного блога Facebook аудитория заметно больше, чем у небольшого личного блога, похоже, что вот отсюда понятие начало расходиться шире. Но Карлос не просто пересказал малоизвестную чужую идею, а дал своё определение:

A «full-stack programmer» is a generalist, someone who can create a non-trivial application by themselves.

Вот такое звучит применимо и сегодня: «человек, который может создать приложение в одиночку». Про дизайн тут ни слова не сказано. И ещё тут нет слова «web», которое было в оригинале — получается, что можно и где-нибудь в геймдеве быть фуллстеком.

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

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

2012: «What is a Full Stack developer?» (Laurence Gellert)

Ещё один резонансный ранний пост — тот самый, благодаря которому словосочетание «full stack» впервые появилось на Хабре. Его тут переводили аж три раза, причём в третий раз — вчера, спустя восемь лет после публикации оригинала.

Здесь определение звучит так:

For me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

«Знаком со всеми слоями, даже если и не мастер в них» — вот это интересный нюанс. Если изначальное определение предполагало «умеешь всё делать хорошо», то здесь этого уже не требуют. Можно быть «T-shaped»: чем-то конкретным заниматься глубоко, а с другими вещами достаточно «быть знакомым».

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

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

Разумеется, этот список породил споры, где к нему пытались что-то добавить или убрать. Но интересно обсуждать не конкретные пункты, а общую идею: тут получается, что для фуллстека важнее не «уметь накодить и на фронте, и на бэке», а понимать и ниже своего кода («как работает то, что накодил»), и выше («зачем вообще нужно то, что накодил»). По сути, тут обращаются к исходному значению слова «stack»: вертикальная стопка вещей, опирающихся друг на друга (недаром тексты про фуллстек часто иллюстрируют стопкой блинов на тарелке).

2014: «Full-stack developers» (Mike Loukides)

Наконец, наткнулся в процессе гугления на популярный текст 2014 года в блоге на сайте издательства O’Reilly. Здесь уже не просто отдельное мнение, а попытка осмыслить различные предыдущие выступления по теме и добавить к ним что-то своё.

Одно из добавлений: вот здесь говорится, что JavaScript к 2014-му страшно разросся и усложнился, так что от фуллстек-разработчиков теперь требуется и понимание всяких ангуляров.

А ещё Майк предлагает к списку «знаний фуллстека» предлагает добавить CVS (ну, сегодня бы уже даже не стал упоминать, наверное), облака, распределённые вычисления… Как он сам признаёт, результат в таком случае получается не вертикальным «стеком», где всё опирается друг на друга, а разветвлённым «деревом», где много вещей «в сторону».

И ещё он признаёт, что если добавить это всё к списку от Лоренса, получается совсем уж длиннющий перечень. Поэтому не требует магического абсолютного мастерства во всём сразу. А вместо этого впрямую произносит слово «T-shaped», призывая специализироваться на чём-то, но в то же время и заглядывать в другие сферы: «я не требую от разработчиков разбираться в сетевых вопросах на уровне сетевиков, но уметь обсуждать эти вопросы надо».

Из забавного: в тексте есть фраза «I sincerely hope that “full stack” doesn’t appear in job titles anywhere». Майк, пишем тебе из будущего, не хочется расстраивать, но тут такое дело…

И что в итоге?

Какие выводы мы можем извлечь из этих четырёх текстов? Своими выводами делитесь в комментариях, а у меня получились такие:

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

А ещё я увидел в этих определениях идею, которую считаю очень интересной. Но надо сделать оговорку: у меня профдеформация, и я тут лицо заинтересованное.

Смотрите: мы привыкли воспринимать «фуллстек» как «фронт+бэк», но сразу два из четырёх описаний совершенно не требуют быть сениором в обеих сферах, а вместо этого идут в сторону «T-shaped». Они предлагают не отказываться от специализации и быть гением-многостаночником, а изучать разное вокруг своего основного.

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

Стоит ли называть это «full stack»? Спорный вопрос. Но для меня как раз это звучит как «фуллстек здорового человека». Потому что про совмещение фронта с бэком часто пишут «здесь боль и страдание», а вот про вылазки на смежные территории такого негатива никогда не слышал — только хорошее.

И если вы хотите быть фуллстеком вот в таком значении, то для вас напоследок сделаю минутку рекламы: мы придумали конференционный вариант как раз для таких людей. Для нашего сезона из 8 онлайн-конференций сделали «Full Pass» — билет-абонемент, дающий доступ ко всем сразу. Смысл в том, чтобы конференцию по своему профилю смотреть внимательно, а на других точечно подключаться к отдельным докладам, актуальным для вас. Если звучит интересно — переходите на сайт Full Pass, там все подробности.

Источник

Чем плохо быть 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 человека. Запрограммировать микроконтроллер для интернета вещей, который общается с веб сервером, пишет в базу данных, и данные с которого можно просматривать на веб сайте, в приложении или на мобильном устройстве? Легко! Вы один можете представить всю систему и реализовать её без согласований, недопониманий и проволочек.

Ваши решения работают быстрее и надёжнее
За счёт понимания взаимодействия различных систем, вы можете выбрать лучше пути для их комбинирования. Вы лучше понимаете каждый компонент и не боитесь его использовать. Как пример — возьмём “кляудные технологии” (мопед не мой, в публикациях проскакивало). В общем и целом, облако это чудесный способ решения огромного количества задач, в том числе задач масштабирования. К сожалению, всё чаще вижу, что облачные решения используются просто потому, что разработчик не умеет и боится решить свою задачу как-то ещё, а представляет это в виде дополнительного плюса. А многое можно сделать гораздо дешевле и лучше, если иметь хотя бы поверхностное понимание вопроса.

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

Вы постигаете дзен
Теперь вы знаете, что нет языка разработки, которых лучше остальных. Вы знаете, что нет самой лучшей базы данных. Вы можете предположить, что какой-то инструмент подходит для ваших целей лучше… но вы вполне готовы использовать альтернативы, если на то есть какие-то основания, например, квалификация остальных разработчиков. Вы больше не пишете статей про синтетические тесты, созданные с тем, чтобы показать преимущества одной технологии над другой. Вы знаете, что прирост производительности в пять процентов скорее всего не стоит двух ваших человеко-месяцев. А освободившееся от холиваров время вы наконец можете потратить на что-то полезное. Например, чтобы наладить взаимоотношения с девушкой (для примера назовём её Катей). Вы теперь понимаете, что технологии бывают разные, что люди бывают разные, и нужно просто найти правильный способ связать всё воедино. Ты любишь мир, и мир любит тебя. Даже когда ты его используешь, чтобы выстрелить себе в ногу.

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

Источник

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 раз при разработке — значит, вы плохо спроектировали архитектуру. Если есть возможность — исправляйте, если нет — обязательно учитывайте это в следующих задачах.

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

Источник

🔩 Как стать фуллстек-разработчиком в 2022 году: дорожная карта и необходимые навыки

Чем занимается фуллстек-разработчик

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

Что включает в себя разработка фронтенда

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

Что входит в бэкенд

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

С чего начать

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

Что должен знать фуллстек-разработчик

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

Рассмотрим подробнее технические навыки, которые вам нужно приобрести.

Понимание архитектуры веб-приложения

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

HTML и CSS

Эти языки – основа фронтенд-разработки. Используя HTML, разработчик определяет структуру веб-страниц. С помощью CSS создаются дизайн и стиль оформления. Для создания интерактивных веб-приложений с уникальным и интуитивно понятным интерфейсом фуллстек-разработчик должен в совершенстве владеть HTML и CSS.

JavaScript

Еще один обязательный язык для фронтенда – с его помощью создаются интерактивные приложения с адаптивным дизайном. Фуллстек-специалисты используют и чистый JavaScript, и библиотеки / фреймворки на его основе – React, Vue, jQuery, Ember, AngularJS и так далее. В дополнение к JavaScript необходимо знать, как работать с интерфейсом DOM и форматом JSON.

Git и GitHub

Git – самая популярная распределенная система контроля версий. Эта система облегчает разработку:

Профессиональные разработчики обычно работают с системой с помощью аккаунта на GitHub. Для работы с Git нужно выучить основные команды системы.

Языки программирования для разработки бэкенда

Для разработки серверной части веб-приложений используются несколько технологий. К самым популярным относятся:

HTTP, REST и SOAP

Знание REST помогает разработчикам создавать масштабируемые приложения, в которых все системы легко обмениваются данными. Сервисы REST выступают в качестве посредников между бэкендом и фронтендом и позволяют наилучшим образом использовать возможности HTTP-протокола. Протокол HTTP используется для передачи данных от сервера к клиенту, а SOAP применяют для обмена сообщениями в XML формате.

Базы данных

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

Менеджер пакетов NPM

NPM входит в состав Node.js. Помогает управлять зависимостями и установкой пакетов, предотвращает появление конфликтов. Обладает гибкими настройками и используется на всех этапах разработки приложения.

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

Для каждой задачи нужен свой набор (стек) технологий. Профессиональный фуллстек-разработчик постоянно отслеживает и изучает новые технологии, чтобы иметь возможность выбрать оптимальную основу для реализации конкретного проекта. Среди самых популярных стеков:

Гибкие навыки

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

Часто задаваемые вопросы о карьере фуллстек-разработчика

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

Можно ли стать фуллстек-разработчиком без опыта?

Это возможно, если у вас есть достаточный объем знаний о CSS, HTML, JavaScript, базах данных, Python или PHP (Laravel). Чем больше навыков вы приобретете, тем больше получите шансов на то, что работодатель заметит ваше резюме.

Что нужно знать, чтобы стать фуллстек-разработчиком?

Нужны всесторонние навыки в создании фронтенда, бэкенда и по работе с базами данных:

Какой стек технологий лучше?

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

Как долго надо учиться на фуллстек-разработчика?

Все зависит от стартового уровня знаний и интенсивности обучения. В среднем, при наличии должной мотивации, на получение базовой квалификации уходит 3-6 месяцев.

Пользуются ли спросом фуллстек-разработчики?

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

Источник

Как подступиться к fullstack-разработке сегодня, если ты проспал десять лет

Привет, Хабр! Несколько месяцев назад у меня остро встал вопрос смены профиля деятельности и я обнаружил, что для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!). Пришлось срочно актуализировать свои знания. Заодно я решил составить шпаргалку с описанием большинства современных технологий, чтобы в случае чего кидать жаждущим новых знаний линк на эту статью, да и самому не забывать.

В качестве вступления.

Зачем это тут? Вполне вероятно, для многих пользователей Хабра всё описанное в статье покажется очевидным. Более того, какие-то аспекты, разумеется уже были описаны более подробно, да не один раз. Однако человеку, который знает только основы (HTML/CSS/JS), всё происходящее, например, в современном JS кажется просто хаосом, в котором решительно ничего не понятно и не ясно даже с какой темы начать изучать вопрос. Когда пытаешься такому человеку что-либо рассказать, упираешься в необходимость рассказывать массу вещей из разных областей, что превращает повествование в кашу.

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

Чтобы не слишком раздувать статью, минимум внимания уделено фундаментальным понятиям, вроде архитектурных решений или паттернов программирования (которые вообще-то неплохо было бы знать априори). Также не будут рассматриваться отдельные обширные вопросы, вроде веб-серверов или особенностей вёрстки на CSS3 — иначе это всё превратится не в обзор, а в учебник.

Также, тут совсем ничего нет про функциональные языки: Scala, Erlang, Haskell, etc.

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

Базовые понятия

Есть один важный аспект, который необходимо рассмотреть более подробно для предотвращения путаницы с понятиями «бэкэнд» и «фронтэнд», а также для более глубокого понимания происходящего в современной web-разработке. Это эволюция самого подхода к формированию HTML отображаемого в браузере. Хотя всё это формировалось, конечно, гораздо раньше чем десяток лет назад, поэтому, вроде бы, должно быть понятно и тому, кто лет десять за тенденциями не следил.

Бэкэнд

Рассматривая оставшиеся технологии, когда речь заходит о том, в каком направлении проще всего найти работу, безусловными лидерами являются три языка — PHP, Node.js и Python.

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

Где-то рядом со всей этой тусовкой топчется Microsoft со своими SharePoint и ASP.Net. Внутри крупных компаний, которым необходима интеграция с Active Directory, это решение часто встречается, но, как уже говорилось выше, данный стек мы не рассматриваем ввиду объёма.

Про Node.js и его экосистему я расскажу в конце статьи, поэтому сейчас, описывая бэкэнд основное внимание уделим Python и PHP.

Про Python.

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

Часто приводят фразу в духе: «что на си занимает 100 строчек кода, в притоне это займет 10». Вот эта «простота» отпугивала, особенно после C++ и любимого С#. Казалось, что язык больше для «домохозяек» и людей не умеющих программировать на нормальных языках с нормальной типизацией, да и вообще язык только для скриптов. Я никогда так не ошибался! 🙂 Язык очень мощный, невероятно удобный, который можно применять во многих областях. Я не знаю ни одного человека, перешедшего с PHP на питон, и который после этого опять хотел бы вернуться к PHP. Это я все к чему веду: питон отличный язык для того чтобы создавать на нем бэкэнд.

Ну а теперь непосредственно про фреймворки… Для начала надо определиться: какой сервер нам нужен блокирующий или неблокирующий. У каждого из них есть плюсы и минусы. Неблокирующий сервер чаще всего используют для веб-сокетов, но на нем можно писать и обычные сайты, способные одновременно обрабатывать большое количество подключений. Но при работе с такими серверами надо помнить, что все подключения крутятся в одном «общем цикле» и блокировка этого «цикла» приведет к полной блокировке всех подключений, в связи с этим все используемые библиотеки должны быть не блокирующими. Среди неблокирующих фреймворков на сегодняшний день я бы советовал использовать aiohttp, есть и другие достаточно популярные такие как Tornado, но все они уступают aiohttp. Что же касается блокирующего фреймворка, то тут выделяется Django. Он подходит для людей, которые любят чтобы все было в одном флаконе и желательно сразу. Django уже «из коробки» включает в себя и шаблонизатор, и ORM, и многие другие удобные библиотеки. Но если Вы, как и, я любите выбирать библиотеки под задачу, тогда советую использовать Flask, а все остальные библиотеки уже настраивать под себя. Шаблонизатор чаще всего используют Jinja2, это достаточно удобный и распространённый шаблонизатор, с которым если и возникнут вопросы, то ответ можно будет нагуглить очень быстро. Что касается ORM, то в мире питона правит sqlalchemy. Это, как пишет создатель peewee (конкурента sqlalchemy): «SQLAlchemy is the gold standard for ORM in the Python world» — и я с ним полностью согласен. Это универсальный и мощный инструмент. Но за все надо платить, в данном случае приходится «платить» сложностью данного фреймворка. Хотя, начать с ним работать можно очень быстро, а вникать в сложности уже в процессе.

Есть очень много и других полезных библиотек, полезных при работе с веб, таких как wtforms, beautifulsoup, Pillow и т.д, но тут все уже зависит от конкретного проекта и задач, которые стоят перед разработчиком.

Я бы еще добавил библиотеку requests (прямо очень мне понравилась). Для облачного serverless бэкенда стоит посмотреть на фреймворки Chalice и SAM. Ну и pipenv, black и flake8 наше все, конечно.

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

Более подробно рассмотрим экосистему PHP, так как несмотря на тонны ненависти от сообщества, старичок живее всех живых и умирать пока не собирается.

В ходу сейчас 7-я версия языка. В первую очередь надо сказать, что различия, ломающие обратную совместимость, есть не только между 5-й и 7-й, но и, например между 7.0.х и 7.1.х (что, кстати, нарушает принципы «семантического версионирования», но всем плевать). В частности, одно из важных изменений, ломающих обратную совместимость в 7.1 — более строгая типизация параметров.

Кроме таких перлов в язык добавилось чуть-чуть синтаксического сахара, а также были убраны некоторые встроенные функции… Была несколько изменена работа часто используемого цикла foreach… Пополнился список слов, которые нельзя использовать для именования собственных объектов (resource, object, mixed, numeric, void, iterable)… Ну и далее в таком же духе, ничего фундаментального, вроде бы.

Если с PHP 4 или 5 вам уже приходилось иметь дело, вы достаточно быстро разберётесь.

Современные PHP-фреймворки

Беглый анализ предложений о работе позволяет выделить наиболее популярные сегодня фреймворки:

Разумеется, это далеко не полный список, однако, как уже было сказано в начале — цель продемонстрировать основные тенденции. Выбрав любой из вышеперечисленных фреймворков для изучения — вы гарантированно найдёте себе работу. Исключение разве что Kohana, но и он поможет быстро понять Laravel, а также может пригодится для небольших проектов.

Самым популярным пакетным менеджером для PHP сейчас является Composer.

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

На самом деле, насколько я понимаю возможности данного пакета, Composer можно использовать не только для проектов на PHP (например, с его помощью можно просто копировать файлы из указанного места, а затем запускать какой-нибудь Bower), однако в этом случае он превращается просто в обёртку для запуска скриптов и это явно не основное его применение.

Другие бэкэнд технологии

Ещё одна штука, часто используемая, например, для ускорения работы с реляционными БД — поисковые движки. Хочется упомянуть Sphinx. Это мощная система полнотекстового поиска, написанная на С++. Представляет из себя отдельное приложение, предоставляющее API для распространённых языков программирования (официально поддерживаются PHP, Python, Java; существуют реализованные сообществом API для Perl, Ruby, DotNET и C++) и интеграцию с существующими СУБД (MySQL, PostgreSQL). Для себя я делаю краткий перевод третьей версии документации Sphinx, если вам подобное интересно, отпишите, пожалуйста, в комментариях, по завершении я выложу его на хабр.

Хотелось бы добавить сюда ещё пару технологий, однако мне явно не хватает опыта в части бэка, чтобы выбрать о чём точно стоит упомянуть. Надеюсь на «помощь зала».

На этом с бэком более-менее всё ясно (не считая Node), поехали дальше.

Фронтэнд

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

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

Я не зря упомянул вначале, что неплохо было бы почитать про ECMA Script, это необходимо для понимания того, почему во многих фреймворках используется, например TypeScript, а не привычный JS (кому-то пришло в голову, что без строгой типизации в JS жить ну никак нельзя, поэтому мы сейчас имеем то, что имеем). От себя скажу, что некоторые дополнительные фишки действительно очень удобны (например классы в ECMAScript 6, позволят писать заметно меньше кода, но мозг ломают знатно). Впрочем лично я являюсь приверженцем использования чистого JS, без всяких надмножеств, и без крайней необходимости новые возможности стараюсь не использовать.

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

На самом деле, про то что происходит сейчас в JS лучше всего написано вот в этой статье. Настоятельно рекомендую её прочесть, если ещё нет.

Я буду более краток, поэтому пройдусь лишь по основным моментам, необходимым для понимания современного JS. Итак, наш отправной пункт это концепция JavaScript-модулей. Чтобы понять необходимость использования этой концепции достаточно рассмотреть простой пример.

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

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

Наиболее часто используемая реализация на данный момент это формат CommonJS. В частности Node.js также использует эту реализацию. CommonJS реализует модули как специальный объект, внутри которого можно объявлять свои функции и переменные, а затем включать их в код в нужном месте с помощью ключевого слова require.

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

Однако теперь, когда встретите в коде JS-проекта ключевые слова «import«, «export«, «require» — знайте, это как раз и есть реализация модулей.

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

Бандлер (bundler) это инструмент для сборки модулей в единые пакеты, имеющий доступ к файловой системе. Бандлер ищет все выражения require (имеющих ошибочный, с точки зрения браузера синтаксис) и меняет их на настоящее содержимое каждого требуемого файла.

При использовании бандлера мы получим из такого кода единый работающий js-файл без выражений require.

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

JavaScript-фреймворки

Сегодня самые популярные направления, охватывающие, пожалуй, процентов 80 всей сферы фронтенда это «большая троица»:

Как видно, на сегодняшний день также считаются популярными Polymer, Ember и Backbone (тут спорно, особенно учитывая, что последний раз его обновили в феврале этого года, а до этого обновления не было года три) и не упомянутый в статистике Meteor. Однако, анализируя предложения о работе, можно видеть, что первая троица имеет наибольший спрос, поэтому описывать остальные проекты я не вижу смысла.

Разумеется, библиотек куда больше, и даже такие «древности» (тут сарказм) как jQuery ещё используются повсеместно. Но для понимания современного WEB вполне достаточно быть знакомым с этой троицей. Хотя тот же jQuery для освоения гораздо проще, чем три упомянутых выше библиотеки — при хорошем знании JS в нём разобраться можно буквально за вечер (и если вы этого не сделали, то определённо стоит).

Пара слов о современных тенденциях разработки фронтэнда. Не хотелось бы пускаться в критику использования реактивного подхода для больших проектов, но всё-таки стоит упомянуть о том, что подход SPA для больших приложений это пока ещё не лучший выбор. Например, на том же Facebook мы можем наблюдать как первая же страница (логин) грузит с сервера больше 4 МБ данных, причём это всё только JS-код. И, если верить тому, что пишут о кодовой базе лицокниги, там есть не только React, но и Angular. Забавно, не правда ли? Если ваш фреймворк такой уж хороший, зачем вам ещё и Angular?

Важное отличие между React и Angular — тип связывания данных модели и представления. В Angular есть как двустороннее, так и одностороннее связывание. Поясню на примере — двустороннее связывание это когда элемент пользовательского интерфейса (поле ввода, чебокс, селект) обновляется, Angular автоматически обновляет данные в модели. React же работает несколько по другому — сначала обновляется модель и затем рендрится элемент, а для изменения модели нужно использовать callback-функции. Где-то удобнее первый вариант, где-то второй. Однако для работы с React нужно чётко понимать, что именно происходит в системе событий приложения.

Сейчас я пишу для двух крупных закрытых проектов, в одном из них абсолютно всё реализовано на чистом AngularJS и всего лишь паре сторонних модулей для него. За четыре месяца я не получил ни одной задачи, которую нельзя было бы решить силами этого фреймворка, хотя некоторые вещи выглядят, конечно, не так красиво как это можно было бы реализовать в React’е, но это скорее частные случаи — как пример можно привести концепцию создания индивидуального scope для каждого компонента, это может быть весьма затратно и неудобно, если компонентов на странице под сотню и они имеют сложное взаимодействие.

Современный подход к CSS-вёрстке

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

Для расширения возможностей CSS сейчас используются SASS и LESS — это динамические языки CSS стилей, которые могут компилироваться как на стороне сервера (SCSS), так и на стороне клиента (LESS, хотя есть и реализации для server-side). Оба этих языка обеспечивают следующие расширения CSS: переменные, вложенные правила, миксины, операторы и даже (ограниченно) функции.

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

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

То есть это даёт возможность сначала загрузить DOM, а потом под него создать специальный CSS прямо на стороне клиента.

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

Node.js

Node.js уже достаточно зрелая технология, продолжающая развиваться семимильными шагами. Это интерпретатор языка JavaScript для серверной стороны (поначалу звучит бредово, да). Сам по себе Node.js является C++ приложением, которое получает на входе JavaScript-код и выполняет его. При этом, нода имеет встроенный веб-сервер (весьма удобный в использовании для мелких проектов, хочу заметить).

О том, как вообще подобная идея появилась очень хорошо написано тут. Статья старая, но для понимания прочесть стоит.

Функциональность Node.js расширяется с помощью пакетов. Пакетом в Node.js называется один или несколько JavaScript-файлов, представляющих собой какую-то библиотеку или фреймворк.

NPM (аббр. node package manager) — это стандартный менеджер пакетов, автоматически устанавливающийся вместе с Node.js. Он используется для скачивания пакетов со своего облачного сервера, а также для загрузки пакетов на эти сервера. Он же отвечает за соблюдение зависимостей между используемыми в проекте библиотеками.

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

Если вы внимательно прочли предыдущую часть статьи, сейчас вам должно стать понятно, как Node.js объединяет фронт и бэк. Используя ноду вы можете писать код на JS (или на чём вам больше нравится — TypeScript, CoffeeScript, ES6 и т.д.), используя возможности шаблонизатора выбранного фреймворка.

Однако, очевидно, что если каждый раз выполнять рендеринг компонентов, постпроцессинг и сборку в один файл, это будет слишком долго. Поэтому на практике, именно такой подход используется только при разработке. Для загрузки в «продакшн» запускают билд проекта, получив на выходе уже готовые файлы, которые уже можно отдавать клиенту с помощью вполне традиционного бэкэнда (PHP, Ruby, да хоть сами сервер на C++ напишите, словом, как угодно). Иными словами, для разработки и поддержки проекта ставить ноду вам в любом случае придётся, поскольку править что-то в этих готовых файлах без исходников проекта это то ещё веселье.

Думаю очевидно, что всё это открывает огромный простор для разработки и широчайший выбор архитектур для построения проекта. Не то что стандартный набор (PHP + HTML\CSS + jQuery ) лет десять назад.

А ведь ещё можно, например, ещё больше унифицировать части кода и использовать их при разработке не только web-приложения, но и мобильного приложения, создавая цельную экосистему (Weex, React Native).

Словом, Node.js, это круто, это хорошо. Осталось чуть подробнее описать самые популярные ныне пакеты и их назначение.

Некоторые популярные пакеты Node.js для разработчиков

Чуть-чуть новомодного сленга, на закуску:

Boilerplate code или просто boilerplate — под этим подразумеваются секции кода, которые должны быть написаны во многих местах с минимальными изменениями или вообще без них — например, код шапки HTML-страниц в шаблонах. Также может использоваться по отношению к языкам, в которых программист должен написать много кода, чтобы выполнить минимальную задачу — например объявление класса с приватными переменными и написание внутри публичных функций, только возвращающих значение этих приватных переменных.

DevOps (акроним от англ. development и operations) — набор практик, нацеленных на активное взаимодействие специалистов по разработке с сисадминами и взаимную интеграцию их рабочих процессов друг в друга. Проще говоря, любому нормальному fullstack-разработчику без девопса никуда, ведь для того чтобы самостоятельно развернуть себе нормальную среду для разработки, надо хотя бы в общих чертах понимать как работает веб-сервер и как его настроить.

Пожалуй, на этом краткий обзор современной web-разработки можно завершить, тем более что он и так получился не таким уж и кратким. Буду рад любым замечаниям.

Upd. В качестве бонуса. Спасибо KonstantinSpb.

Источник

Бытие современного фуллстек-разработчика

Я живу на периферии технологической тусовки. И на периферии в географическом смысле. А это значит, что:

Наверно, достаточно. Кто же я такой, и что я делаю на Хабрахабре? Дело в том, что я… Я — перманентный выживальщик. Другими словами, современный фуллстек-разработчик. Ох, представляю, как поморщились сейчас профильные программисты! Фуллстек… Что я им могу сказать? Ребята, я рад бы был прокачивать навыки в одном направлении. Рад бы был, как и вы, погрузиться в тему и становиться узкоспециализированным гуру. Но, к сожалению, реальность такова, что в регионах человеку на удаленке приходится хвататься за любую работу, лишь бы не идти аникеить или не становиться таксистом.

Какими языками мне приходилось заниматься, и выдавать законченные вещи? Если сделать выборку по шкале времени, то получится такой список:

Да, мне самому страшно от этой сборной солянки. Что за фееричные метания? Вот прямо так? Веб — прочностной анализ — складской учет — геймблинг… Атомные станции, картография, телефония. Автор, ты серьезно? Абсолютли! Жизнь прижмет — еще и не так раскорячишься.

Грань перехода

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

И для полноты картины еще пара публикаций:

А про самую нижнюю строку таблицы «Веб-разработка и телефония» я расскажу далее в этом тексте.

Итак, перспективный проект мобильного приложения под Android для кастомного навигационного оборудования резко закрывается. Еще вчера разработчик писал бекэнд-код на C++ и фронт на QML, прикручивал нативный код к Java через JNI, а сегодня он судорожно должен искать вакансию C++ разработчика на удаленке. Современный рынок C++ таков, что найти в России работодателя с C++ на удаленке — это большая удача. Все работодатели хотят видеть программиста C++ в офисе. Месяц в поиске — полный ноль. Пора переквалифицироваться, благо бэкграунд позволяет.

Определение

Фуллстек-разработчик (представитель семейства специалистов по всему) — мифический персонаж, предмет вожделения работодателя, мечтающего оптимизировать производство ПО до команды из одного человека. Фуллстек-разработчик обладает магическими способностями: имеет бездонную память, ибо знает все современные языки и технологии; в мозг интегрирован глобальный понятийный аппарат, превосходящий по организации мыслительного процесса Владимира Ленина, Альберта Эйнштейна и Леонардо да Винчи; системное мышление такого специалиста способно производить дебаг чего угодно прямо в мозгу, без применения средств отладки. Неприхотлив, питается солнечным светом.

Переход на новую задачу

Неожиданно на меня выходит хабрапользователь itsar, и берет в свою команду. У него висит несколько задач, и на пробу я реализую прототип веб-сервиса. По задумке, веб-сервис оповещает пользователей о различных событиях по различным каналам связи, включая телефонные звонки. В результате появился сайт QrCall.org, про который уже писалось на Хабрахабре: Поди туда — не знаю куда.

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

Чтобы было понимание, к сегодняшнему моменту этот веб-сервис выглядит так (девелопер-версия):

Выбор инструментов

Телефония

Больше всего беспокоит будущая реализация телефонии. Осилю ли я? Сразу понятно, что придется работать с SIP, но каким образом? В мозгу болтается воспоминание, что когда-то игрался с каким-то консольным SIP-клиентом, и даже мог набрать телефонный номер и совершить звонок. Для решения задачи этого будет достаточно. В крайнем случае придется заморочиться с Asterisk. Звоню знакомому связисту, описываю суть проблемы, прошу напомнить что за консольный клиент я мог щупать. Вердикт однозначный — это Linphone и его консоль linphonec. Но набрать номер в консоли — этого мало. Надо еще проиграть в виртуальную трубку звуковой файл. Устанавливаю Linphone, захожу в его консоль, смотрю возможности. Так, есть возможность переключиться со звукового дейвайса на файл. Это хорошо. И в консоли есть команда play, которая запускает звуковой файл на проигрывание. В принципе, больше ничего и не нужно.

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

Фреймверк и пакетный менеджер PHP

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

Далее вопрос по фреймверку. Выясняю, что в 2019 году Yii2 уже не актуален, а Yii3 застрял в каком-то промежуточном состоянии. Что остается? Для Zend и Symfony я еще не созрел, поэтому вариантов практически нет — только Laravel. Читаю документацию, смотрю обучалки, заказываю книжку русскоязычного автора (оказалась очень толковая, то что надо для старта). После древнего Codeigniter и неактуального Yii фреймверк Laravel понимается легко, сразу видно как продвинулась программистская мысль в проектировании веб-приложений. Все, о чем мечталось уже реализовано, обкатано и обросло стандартными подходами. Да, проект планируется не нагруженным, так что могу себе позволить некоторую нубскую кривизну в реализации.

Ставлю Laravel «по дефолту», предлагая Composer самому решить, какая версия Laravel в данный момент актуальна. Он ставит 5.5. Ну ладно, пусть будет эта версия, она более обкатана чем 5.8, значит будет проще решать проблемы. Мы не гонимся за нововведениями.

Для работы некоторых компонентов Laravel, например для системы сборки и минификации CSS-файлов Mix (надстройка над Webpack), требуется серверная среда выполнения JavaScript-кода Node.Js и написанный на JavaScript пакетный менеджер npm. В Debian Linux Stable, который я использую, уже есть пакет npm. Однако он достаточно древней версии, и не подходит для инфраструктуры Laravel 5.5. Разбираюсь, как ставить из сторонних источников, нахожу deb.nodesource.com, ставлю с него. Хм, странно, в том же пакете, вместе с Node.Js ставится и npm. Это совсем не Unix-way, ну да ладно. Главное, что работает.

Верстка

Идея проекта QrCall.org — вызов пользователя через QR-код. А это значит, что посетители будут заходить на сайт с мобильных устройств, с помощью камер которых этот QR-код будет сканироваться. В то же самое время, регистрация пользователя, настройка оповещений и печать QR-кодов, скорее всего, будет производиться с десктопных компьютеров. Значит, без адаптивной верстки не обойтись.

Сразу отметаю генерацию мобильного/десктопного контента на сервере путем анализа UserAgent. Это не наш подход для 2019 года. Тут однозначно нам поможет CSS-фреймверк Bootstrap. Вообще, верстка веб-приложений — это отдельная, гигантская, большая тема, которой должен заниматься отдельный специалист. Для меня в веб-разработке нет ничего более сложного, чем ковыряния с версткой. Я давно понял, что у меня версточный кретинизм. Я трачу колоссальное количество времени, чтобы сделать очередной правильный отступ, или выровнять несколько элементов. Но ресурсов на верстальщика у нас нет, поэтому приходится делать как можешь, желательно чтоб результат был ровным и красивым.

Встает вопрос: какую версию Bootstrap использовать? 3 или 4? Выясняется, что Bootstrap сразу идет в комплекте с Laravel 5.5, и это версия 3.x. Разбираться с тем, как переделывать окружение на Bootstrap 4 времени нет, поэтому оставляю версию 3. В конце концов, в интернете сотни тысяч сайтов используют Bootstrap 3, а значит это достойная для использования технология.

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

Вот как выглядит страница в десктоп-версии:

А вот она же в мобильном представлении:

Разработка

Как будет использоваться фреймверк? У меня такой подход: по максимому использовать все готовые компоненты фремверка, но с одним условием: если есть хорошее понимание, как этот компонент работает. Как сказал один человек, который уже познал дзен Laravel, «Речь не про то, что документация написана на нерусском языке, а про то, что даже на родном для фреймворка английском она не всегда показательна». Поэтому, я считаю, что если не удается быстро разобраться с компонентом или методикой, лучше сделать как-нибудь попроще своими методами, чем писать слабо понятный самому себе код.

О чем я говорю? Фреймверк Laravel — это большой фреймверк с множеством реализованных абстракций и со своим подходом к структуре кода. В нем есть простые вещи, давно и успешно применяемые как в Laravel, так и в других фреймверках. Есть сложные, но понятные вещи, например, реализация очередей (которые придется использовать для телефонии). А есть действительно сложные фундаментальные вещи, вникнуть в которые с наскоку не получится. Например, это связка Сервис-контейнер + Сервис-провайдер + Фасад. К настоящему моменту я пока понял как чисто механически сделать Сервис-провайдер, разместить его в Сервис-контейнере и прикрутить ко всему этому фасад. Но для чего это нужно делать — я пока не осознал. Вроде как этот подход сокращает код, можно обращаться к абстракции и ее методам в статическом стиле, не используя ключевое слово new (сомнительное достоинство). И еще использование фасадов позволяет легко организовывать автоматизированное тестирование веб-приложения, а как побочный эффект от всего этого удобства, при использовании сервис-провайдера автоматизируется внедрение зависимостей. В общем, пока понимания нет, мне проще всего обходиться обычными классами-хелперами, что я и делаю.

Технологии

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

Да, не самый модный и продвинутый стек. Но нам нужно делать дело, а не упражняться в оборачивании окружения в Docker-контейнеры и не продвигать идею JS-only разработки.

Очередь

Очереди — это весьма специфическая предметная область, и в крупных командах за очереди обычно отвечает специально обученный специалист, обеспечивающий работу очередей на сотнях серверов. В нашем случае сотен серверов не наблюдается, поэтому необходимо использовать очередь максимально просто и по делу. Поэтому в качестве хранилища заданий я решил использовать уже используемый в проекте движок реляционной базы MySQL. Был некоторый соблазн сделать по уму, например на базе Redis, но разбираться с этой NoSQL БД времени просто не было.

В ходе разработки появился запрос на задачу, которую невозможно было напрямую решить средствами очереди на MySQL, но которая решалась бы при использовании Redis. Проблема была в том, что после успешного выполнения задания, задание из очереди удаляется, и нет никакой возможности проверить, выполнялось ли, например, определенное задание в течении последних 10 минут? При использовании хранилища Redis это можно было бы реализовать через Rate Limitting, а вот при использовании MySQL такой возможности нет. Поэтому пришлось реализовывать подобный функционал просто на основе аналитики лога действий. Благо что лог действий — это непременная часть нашей небольшой информационной системы.

Платные сервисы

При размещении сайта в сети Интернет, необходимо закладываться на оплату различных услуг. Хостинг и доменное имя — это всегда практически обязательные платежи. Хостинг взяли недорогой, оплатили 2Gb оперативки, из расчета 1Gb на базу данных, остальное — на операционку и выполнение скриптов. В тарифе шло 2 ядра микропроцессора, хотя с нашими нагрузками, думаю, отлично справилось бы и одно. Дисковое пространство в 20Gb более чем достаточно для нашего проекта. В процессе развертывания потребовалась компиляция linphonec, потому что на моем десктопе разработчика стоял более древний Debian Linux, чем в готовом образе виртуалки, предоставляемой хостером, а стандартный пакет из репозитария содержал древнюю версию этой программы с несколькими неприятными «особенностями». И вот, на компиляцию linphonec, мне 2Gb и не хватило. Магия шаблонов в C++ выжирает память как не в себя, поэтому пришлось настроить своп, после чего сборка успешно завершилась.

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

В наших современных реалиях нельзя расчитывать на то, что найдутся бесплатные сервисы Email-рассылки. А Email-рассылка в нашем случае нужна для отправки различных оповещений. По моему опыту, все попытки организовать отправку множества писем через Яндекс.Почту или через Google.Mail приводят только к тому, что почтовые серверы принимающей стороны, после трех-четырех писем, помечают сообщения как спам. То есть проблемы возникают уже на этапе отладки, не говоря про продакшен. Поэтому пришлось заморочиться с сервисом Mailgun, через который письма доставляются быстро и без проблем. С Mailgun только одна непонятка: в некоторых статьях пишут, что они дают бесплатно отправить 10000 писем ежемесячно. А на сайте самого Mailgun как-то скользко написано, что я понимаю как 10000 писем с момента регистрации. В любом случае, этот предел сервис пока не преодолел, так что надо просто понаблюдать.

Трудностей с настройкой Mailgun немного. Вначале надо заморочиться, и сделать правильные настройки в аккаунте, привязав его к своему доменному имени. После чего, можно сделать тестовую отправку письма с сайта с помощью любой подходящей команды или скрипта, например через SMTP. А в Laravel есть даже готовый драйвер соединения с Mailgun, благодаря которому даже не нужно настраивать почтовую подсистему для отправки писем на уровне операционной системы.

Фаирвол

Фаирвол я всегда настраиваю просто и примитивно, всего тремя правилами. Первое правило для INPUT разрешает прохождение пакетов для установленных соединений. Второе правило разрешает установку соединений на определенные порты. Главное не ошибиться, и не забыть про порт для SSH, а то будет ой. Третье правило — DROP всех остальных пакетов цепочки INPUT. Конечно, в этой схеме возможны варианты, но базис именно такой.

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

Бэкап

Сейчас на сервере крутится самописный скрипт, который обкатан на других проектах. Он получает на вход перечень команд и перечень каталогов. Перечень команд — это команды, которые нужно выполнить перед бекапом, например команды снятия дампа MySQL. А перечень каталогов — это каталоги, содержимое которых надо забекапить. В результате получается zip-архив, который складывается в определенный каталог, и скрипт следит, чтобы таких архивов не складывалось больше определенного количества. Если больше — удаляются более старые файлы архивов. Каталог с архивами синхронизируется с другим хостом через rsync.

Я понимаю, что такой подход — это сплошные костыли, поэтому планирую переехать на бэкапы через borg. Но пока настроено таким образом, как мне проще и удобней.

Деплой

Для деплоя я использую систему контроля версий GIT и специально написанные скрипты, разбитые на этапы, имеющие один центральный скрипт запуска. Разрабатываемый код пушится на сервер центрального репозитария. В момент, когда нужно обновить сайт, запускаются скрипты, которые выполняют часть команд от рута (остановка и старт всяких сервисов), а часть команд от веб-сервера (получение кода через git, запуск утилиты artisan). Для этого сделаны настройки в /etc/sudoers и заданы права доступа на файлы скриптов так, чтобы они могли выполняться определенным пользователем, но не могли быть изменены никаким другим сторонним пользователем.

Благодаря тому, что в Laravel есть система миграций, никаких сторонних утилит для обновления структуры БД и наполнения таблиц первичными данными не требуется. По сути, при деплое происходит только перенос кода, и этого достаточно. Система пережила уже несколько штатных обновлений, пока что полет нормальный.

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

Недоработки

Все мы умны задним числом. Пора подумать, были ли допущены стратегические просчеты? Да! Можно было бы что-то сделать лучше? Конечно, да! Ниже я перечислю просчеты и недоделки этого проекта. Некоторые вещи исправить достаточно просто, некоторые требуют больших временных затрат.

Крупным просчетом было то, что я понадеялся на дефолтную установку Laravel, и использовал в качестве CSS-фреймверка Bootstrap 3 вместо Bootstrap 4. Все-таки Bootstrap 4 шагнул далеко вперед по сравнению с Bootstrap 3, и помимо flex-верстки в нем появилось много тех вещей, которых в Bootstrap 3 просто не было, и которые приходилось делать руками. Сейчас можно переползти на Bootstrap 4, но верстка обязательно поедет, а с моим версточным кретинизмом выправлять её придется очень долго.

Все современные сайты, работающие с аутентификацией пользователей, обязаны работать на протоколе HTTPS. К сожалению, у меня пока не дошли руки до этого этапа, а этап очень важный. У меня уже есть опыт перевода сайтов с HTTP на HTTPS, я даже написал себе памятку Настройка сертификатов Let’s Encrypt HTTPS на веб-сервере NGinx, однако нужно выделить время чтобы этим делом заняться.

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

Тестирование. Да, я очень сильно страдаю от того, что у меня нет времени на создание системы тестирования. Я не пишу юнит-тесты, так как разработка связана по большей части с созданием пользовательского интерфейса и отображением действий пользователей в интерфейсе на базу данных. По большому счету, мне необходимо организовывать систему функционального тестирования. К сожалению, времени на это просто нет, а отдельные тестировщики не предусмотрены. Я знаю, что в Laravel есть хелперы именно для функционального тестирования, и, если проект будет развиваться, я попробую закрыть этот технологический долг. Судя по описанию, сделать блок из тестов, которые хотя бы просто проверяли коды ответов страниц, достаточно просто.

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

Должен ли современный разработчик разбираться во всем этом феерическом калейдоскопе знаний? Вопрос здесь в слове «разбираться». Что значит разбираться? Разбираться можно по-всякому, поэтому нужно еще ввести такое понятие, как глубина погружения в тему. Так вот, с этой точки зрения, я считаю, что человеку достаточно иметь представление о технологиях, и не загружать мозги подробностями. Гораздо важнее иметь способность быстро разбираться в новых вопросах, если придется трудиться над задачами из новых предметных областей.

Понятно, что разработчик, работающий в режиме «и швец, и жнец, и на дуде игрец» не может глубоко знать технологии, с которым он работает. Современные средства разработки колоссально сложны и обширны. Тот же язык Си++ нужно учить и использовать пару десятилетий, пока не появится легкость в его применении. Изучение должно сопровождаться полным набором сопутствующих вещей: профессиональный коллектив, общение с коллегами и возможность обсуждения вопросов «на коленке», конференции, обучение, литература, академическая среда, большие и интересные проекты. Это касается любого языка и ИТ-технологии. Фуллстек-разработчик на удаленке этого набора априори лишен, и может рассчитывать только на самого себя. К сожалению, я вижу, что освоение сложных вещей очень непроизводительно в одиночку. Тематические форумы и телеграм-каналы тут мало помогают: куче народа давным давно плевать друг на друга, и если обсуждение какого-либо вопроса не выльется в флейм, оскорбления, лицемерие и оценку профессиональных и умственных способностей вопрошающего, то это будет большой удачей.

Более поверхностные знания — это та плата, которую приходится платить фуллстек-разработчику за то, что он может, с помощью своих обширных знаний и навыков, делать достаточно дёшево разнообразные информационные продукты. Можно называть такие продукты прототипами, proof-of-concept, или еще как, но факт в том, что лучше иметь прототип и развить его в более крупное дело, чем не иметь вообще ничего. Или, другая крайность — сильно потратиться на разработку продукта, а потом выяснить что его невозможно никуда приткнуть.

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

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

Источник