Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Для чего Back-end разработчику учить JavaScript

Меня зовут Алексей Голубев. Я Lead Software Engineer в GlobalLogic. В общей сложности в IT работаю более 6 лет. Занимался pentesting, разработкой desktop, web, mobile. Стек: .NET, C#, JavaScript. Начинал с back-end, позже стал делать и client-части приложений.

Сегодня хочу поговорить о том, для чего бэкенд-специалисту может пригодиться JS в контексте разработки клиентской части. Под JavaScript я буду подразумевать и TypeScript, и Flow. Речь, конечно, не о полном отказе от бэкенд-обязанностей, а о расширении компетенции в сторону клиентской части, ведь JS — это почти синоним браузерного клиента.

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

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

  • А есть ли на ваших проектах такие задачи, которые реально требуют узкой компетенции? Ведь большинство проектов — это типичный CRUD, а многие вещи, например авторизация, уже даются в готовом виде.
  • А точно ли убывают старые знания, если прибудут новые? Конечно, бывают сложности в работе, когда долго что-то не практикуешь. Но так будет со всем, даже внутри библиотек самого back-end. Тут без разницы, учить новый JS-фреймворк или новый web-движок.
  • А точно ли современные технологии так сложны в освоении с такой кучей мануалов, видеокурсов, статей и обучающих сайтов?

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

А теперь о языке и бенефитах

JavaScript — это уникальный язык. У других языков нет такого огромного комьюнити, нет столько хейтеров и почитателей, нет такой распространенности. Стоит посмотреть топы GitHub trends или статистику по самому GitHub, чтобы увидеть тенденцию: JavaScript развивается. Более половины разработчиков пишут на JS, по данным Stack Overflow.

Для JS больше всего написано пакетов и готовых библиотек. Каждый год ему придумывают альтернативу. Но эти альтернативы либо в итоге компилируются в JS, либо в WebAssembly, который на продакшене видели единицы.

Пожалуй, лучшая попытка, заслуживающая внимания — это TypeScript, который имеет синтаксис JS + типы и компилируется в JS.

Рок-н-ролл мертв, а JS еще нет. И, судя по всему, все у него будет хорошо, чего нельзя сказать о других языках.

Так зачем же пополнять ряды всех этих «несчастных» за счет бэкендеров?

Оперирование фичами вместо тасок. Обычно, когда приходит большая фича, она делится на front- и back-части. Владея JS, Back-end Developer может взять на себя все обязанности и делить задачу по своему усмотрению. Это удобно и ускоряет процесс, так как исчезает дополнительное согласование API и поведения. Один разработчик может деливерит большой кусок функционала и быть ответственным/ответсвенной за него.

Универсальность. Мы работаем на результат, который достигается всей командой. Но иногда в команде бывают проблемы со смещением нагрузки с back на front и наоборот. Зная JS, Back-end Developer может маневрировать и перетягивать на себя часть задач с фронта. Гибкость, особенно в условиях аутсорса, — это очень важное качество.

Архитектура. Дело в том, что сам по себе back-end не существует в вакууме. Являясь обычно server, он взаимодействует с client, который, в свою очередь, может быть и мобильным приложением, и веб-страницей, и десктопом. Таким образом, понимание всех плюсов и минусов клиента поможет в формировании архитектуры приложения.

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

Попробовать что-то новое. Про количество npm-пакетов ходит много шуток. И у Back-end разработчика/разработчицы есть огромные возможности не сидеть на старом заезженном стеке, а попробовать что-то новое. Ведь наш back-end довольно консервативная штука в отличие от front-end, этим стоит пользоваться.

А есть ли минусы?

Минусы есть, для кого-то они вполне существенные.

HTML, CSS. При смене языка программирования меняется по большей части API. Многие вещи остаются похожи, ведь языки не развивались в вакууме, а заимствовали что-то друг у друга. Про HTML и CSS так сказать нельзя. Это другой мир с другими принципами работы, поэтому все, что связано со стилями, будет страдать. Но есть несколько нюансов, Material, Bootstrap и так далее. Эти фреймворки помогут в верстке почти любого проекта, если же он не дико кастомный и дизайн не опирался на готовые решения.

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

Например, часто возникают проблемы с сервисами в AWS, Azure или настройкой того же SonarQube. В таких случаях можно поискать экспертов внутри компании или аккаунта. Главное — не забывать, что настроить следует самому/самой, а эксперт нужен для совета, тогда это будет максимально продуктивно.

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

Например, постоянный холивар хранить авторизационные данные в cookie или в localStorage (спойлер — в cookie безопасней), чтобы было удобней оперировать и бэкенду, и фронту.

С чего начать?

Сперва стоит найти несколько составляющих.

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

Время. В идеале пройти курс по JS/TS и интересующему фреймворку. Подойдут Udemy и Coursera из платных, Metanit, learn.javascript из бесплатных. Я бы не рекомендовал браться за фреймворк без изучения азов языка и синтаксиса ES5/6. Будет не лишним знать TypeScript, так как все больше компаний переходят на него в связке с тем же React. Все зависит от проекта, к которому вы готовитесь.

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

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

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

Что в итоге?

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

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


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

А что вы думаете, куда должен развиваться специалист? И должен ли он развиваться вообще, может, опыта на проекте достаточно и все эти курсы — просто трата времени? Напишите в комментариях.

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

LinkedIn

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

43 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Цікаво, а коли взагалі в ІТ з’явився поділ на фронт-енд і бек-енд? Адже в 2000-і ніхто про це чув і не знав. Людині ставили завдання — написати програму або сайт, люди це і робили.

Фронт поступово ставав складнiшим i на розробку треба було все бiльше часу. Тому I виникла спецiалiзацiя. Пам’ятаю десь роцi в 2008 у нас в конторi з’явився окремий девелопер, який займався виключно js’ом.

Я думаю, що справа не тільки в цьому. Візьміть, наприклад, бази даних. Вони теж стали набагато складніше за останні 20 років (я вже мовчу за NoSQL), але ж ними як і раніше займаються бекенд розробники. Я про програмування, та й конфігурування (окремий DevOps зараз мало де є)

На мою думку це тому, що коли йде розробка «звичайоного проекту», то нiхто не знає, чи «вистрiлить» проект чи нi. Чи буде купа користувачiв, велика конкурентнiсть та датасет. Тому не наймають спочатку dba, не планують iнфрастуктуру та як буде маштабуватись проект.

Але, задачi пов’язанi з iнтерфейсом користовача, та бiзнес-логiкою починаються з першого ж дня. I необхiднiсть у цих спецiалiстах виникає одразу. А коли проект виходить на певний рiвень навантаження, то там вже з’являються i dba, i devops.

p.s. а сереньостатистичний backend-девелопер не дуже розумiється на сховищах (rdbms, nosql), як там все працює всерединi та якi є налаштування шоб db-iнстас витримав хоча б 10K rps, та 1TB данних.

В комментариях прям комбо хейтеров js и фронтенд-разработки

Зазвичай людина не сильно любить позбавлятися стереотипів...

Основное, что может подчерпнуть для себя back-end разработчик из JS (и о чем ни слова не сказано в статье) — это прототипное наследование, событийная модель, асинхронное и реактивное программирование. Новые фреймворки и библиотеки гроша выеденного не стоят в контексте саморазвития. Парадигмы и паттерны — это то что отличает программиста от формошлепа. Они расширяют кругозор программиста и позволяют мыслить шире.
Абсолютно неважно, на каком языке или какой части стека Вы пишите в данный момент. Освоив перечисленное выше, освоить условный react/angular/vue — дело недели-двух. Даже для законченного пехепешника, типа меня.
А HTML и CSS — это не работа full-stack-а, если мы, конечно, говорим о программистах. Нет, разбираться в этом на базовом уровне, конечно, нужно. Но на крупных проектах, декомпозиция стилей — это отдельная задача для отдельного специалиста.

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

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

Ведь большинство проектов — это типичный CRUD

По сути, любые операции между клиент — сервер можно назвать типичным CRUD. Но дьявол кроется в детялях,и «типичный CRUD» обрастает какими нибудь batch операциями с XX ( XXX ? ) сущностями, где на каждую операцию еще идет куча под событий.

многие вещи, например авторизация, уже даются в готовом виде.

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

А точно ли убывают старые знания, если прибудут новые?

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

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

А точно ли современные технологии так сложны в освоении с такой кучей мануалов, видеокурсов, статей и обучающих сайтов?

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

Саммари — у многих людей наблюдается эфект Данинга — Крюгера. Многие люди, ошибочно думая, что являются джедаями в своей области, пытаются сидеть сразу на 2 области. В итоге становятся Эдакими jack-of-all-trades, обладая посредственными знаниями в обоих областях. Это ок на маленьких проектах или стартапах никогда не выходящих в продакшн, но подобные знания мало пригодятся на более крупных проектах.

Сам встречал несколько реально классных full stack, которые были и js ниндзя, и backend гуру, эдакими сеньорами с обоих сторон, или хотя бы middle+ с обоих сторон,но они — ошибка выжившего и встречаются реже чем единороги на Крещатике.

они — ошибка выжившего

у вас какой-то грустный опыт

это уникальный язык

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

так как исчезает дополнительное согласование API и поведения.

 ну это достигается совершенно другими способами, и одному делать все нет совершенно никакой необходимости, вот например как это делает protoforce io. Просто пишете протокол на языке для описания протоколов и забиваете на согласование API, потому что язык вам это все дело сгенерирует.

Таким образом, понимание всех плюсов и минусов клиента поможет в формировании архитектуры приложения.

бекенду по барабану кто и откуда его дергает главное чтобы протокол соблюдал.

Шире выбор проектов.

не достоинство, никогда бы не хотел работать с жс.

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

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

ідеальний для певних типів задач

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

Можна подумати на Скалі прям перфєкто-ідеалє виходить... Ідеальної мови програмування не існує. Є звички та стереотипне мислення.

очікував хоча б згадку про node.js, але шось пішло не так... )

Ведь плато в знаниях не существует: ты либо идешь вверх, либо скатываешься вниз.

Фулстек это не вверх, а вширь.

И в итоге с этой невинной подмены некоторые пункты звучат манипулятивно.

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

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

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

А поучить другой ЯП раз в пару лет да, полезно.

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

Для того чтобы тролить фронтов тонко?)

Ведь наш back-end довольно консервативная штука в отличие от front-end, этим стоит пользоваться.

Очень смелое и ничем не обоснованное заявление. backend развивается очень интенсивно и новые возможности, веяния и решения требуют очень серьезного времени на разбор и изучение.

backend развивается очень интенсивно
Очень смелое и ничем не обоснованное заявление.

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

«Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.»

Я с такими пацанами поработал 2 недели. Только у них ещё и мобильщина была на JS.
Вместо дурки был её армейский вариант. Принципиально в 2015 году:
— голый JS
— CVS как хранилище всего
— однобуквенные имена переменных
— никакой встроенной документации
— коммит-сообщения подробнее «update» — потеря времени
— все правки в прод с колёс
вспоминаю с лёгким офигением.

Все так. Самого иногда выбешивает в JS и PHP комьюнити норма вот такого развития разработчиков:

— Делаю сайт, буду программистом!
— Взял фреймворк, говорят модный, учусь использовать
— ой, он ООПшный, с элементами функциональщины, сейчас бытенько разберусь
— вот же ж, паттереы-правила ещё какие-то, полистаю «совершенный код»
— Какие-то навороты понаписаны, сказали что это килерфичи языка программирования, и надо проработать «Вы не знаете Javascript». Ну ладно, доделаю сайт,гляну на ютьюбе пересказ, за 15 минут, во время завтрака, я ж уже и так знаю ЯП,и умею код писать!

А надо бы в обратном порядке... и ещё пару пунктов после изучения ЯП.

Главное чтобы не было статей: «Для чего JavaScript разработчику учить Back-end»

Плюсы и минусы фулстек разработки
Плюсы — бизнесу хорошо, продакт овнерам хорошо, проджект менеджерам хорошо, Деливери менеджерам хорошо.
Минусы — разработчикам плохо

а почему разработчикам плохо? :)

Потому что
1. Надо переключать контекст при переходе от фронтовых тасок к бэковым и наоборот
2. Квалификация фулстеков в большинстве случаев оставляет желать лучшего по сравнению с фронтовыми и бэковыми сеньорами, надо вечно следить за трендами и новыми подходами с обеих сторон и начинается включаться синдром самозванца. Вот бедные и пытаются повышать квалификацию но часов то в сутках — 24
3. Когда пытаешься нанять таких спецов, на собеседованиях очень сложно правильно расставлять акценты и начинается или лютый упор на бэк с его микросервисами, ddd и перформанс оптимизациях или начинаешь спрашивать за последние фичи реакта, или всяких CSS-ах с его выкрутасами и хаками. Результат — такой же как и в 2 пункте

лютый упор на бэк с его микросервисами, ddd и перформанс оптимизациях
последние фичи реакта, или всяких CSS-ах с его выкрутасами и хаками

Так вы, батенька, фулстек?)

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

Как же устал разгребать «фронтенд» от «фуллстеков»...

А теперь представь себе что они в бэке пишут.

Та так и пишут, будто у них осталась возможность нажать F5
Ну и монга потому «лучшая» — на локалстор браузера потому что «похожая».

Без знань HTML та CSS можна такого нафулстекать... Деякі задачі вирішуються правильною структурою HTML та CSS, взагалі без JS. Але це вже інша історія, бо сучасний тренд — react, react та в продакшин...

Все правильно) Потому что если не будет прода то «правильна структура» вам смузи не оплатит ;-)

та ну навіть з реактом купу всього можна CSSом зробити.

Можна. Але для цього треба зусилля та знання.

у Back-end разработчика/разработчицы есть огромные возможности не сидеть на старом заезженном стеке, а попробовать что-то новое. Ведь наш back-end довольно консервативная штука в отличие от front-end, этим стоит пользоваться.

Пока закончишь читать название нового фронтенд фреймворка, он уже успеет устареть.

Ага. Больше похоже на троллинг.

Вспомнилась шутка о том, для чего курица перешла дорогу

В cледующих сериях наших занимательных статей читайте:

Для чего Back-end разработчику учить HTML
Для чего Back-end разработчику учить CSS

Садишься такой в такси к фронту, а он говорит: Это я просто подрабатываю,у меня вообще свой бекенд есть

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