Для чего 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. Основная цель статьи подстегнуть интерес к обучению. Ведь плато в знаниях не существует: ты либо идешь вверх, либо скатываешься вниз. Выбор за вами.
