Фронтендер это: подробный разбор профессии — CheckROI

Кто такой frontend developer и что должен уметь фронтенд-разработчик

Если вы в душе дизайнер, но любите программирование и верите, что будущее за internet-технологиями, для вас интересной будет специальность Frontend-разработчика, так как она требует некоторых творческих способностей и глубокой практической подготовки по web-программированию. С помощью языка разметки страниц HTML и каскадных таблиц стилей (СSS), вы сможете создавать дизайн web-приложений, интерфейсы сайтов, подавать информацию в привлекательном виде, приятном и удобном для пользователей. На Frontend-разработчика также ложится часть ответственности за рейтинг разрабатываемого сайта, так как чем понятней будет интерфейс, чем более подходящим способом будут структурированы данные, тем больше времени пользователь уделит сайту. В данном случае разработчику просто необходимо разбираться в дизайне и теории цветов, чтобы сайт не выглядел слишком угрюмо, но и не подавлял яркостью цветов и огромным размером символов.

Знания CSS и HTML помогут разработчику сделать красивую статическую страницу, но при работе с сайтом пользователям необходимо взаимодействовать с информацией. Поэтому разработчик должен знать скриптовый язык программирования JavaScript, который делает web-страницы функциональными и интерактивными. Также применение JavaScript способствует корректному отображению страниц на устройстве пользователя, так как некоторые браузеры понимают стандарты CSS и HTML по-разному. Багаж знаний Frontend-разработчика включает также знания библиотеки JavaScript — jQuery, которая необходима для взаимодействия JavaScript и HTML. Данная библиотека используется для работы с AJAX, еще одной технологии для разработки web-интерфейсов. Технологии AJAX выполняют взаимодействие клиентской части с серверной стороной. С использованием данных средств работа приложений стает быстрее и динамичней.

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

Такой большой перечень требований оправдан, так как специалист в этом направлении может получать от 500$ до 2500$ в зависимости от уровня знаний и опыта работы. На данный момент рынок труда заинтересован в специалистах такого плана и в будущем спрос на них будет только расти, ведь использование интернета, интернет-технологий за последние десять лет выросли практически в геометрической прогрессии. Почти каждая фирма, организации, предприятие имеют свой сайт и нуждаются в специалистах обеспечивающих работу этих сайтов. Существует множество интернет-компаний, IT-компаний, где Frontend-разработчик может применить свои знания.

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

Требования к Frontend разработчику:

• Знание HTML, CSS
• Знание языка программирования JavaScript
• Опыт работы в HTML5, CSS3
• Хорошее понимание JS фрeймворков (Angular2/jQuery/ReactJS/Node.js)
• Знакомство с MVC/MVVM design patterns
• Умение анализировать, изучать, осваивать и применять новые технологии
• Английский язык на уровне не ниже Intermediate

JavaScript/FrontEnd разработчик может занимать такие должности:

Web разработчик
FrontEnd Developer

Junior/Middle/Senior JavaScript Developer

Node.js/ReactJS JavaScript Developer

Frontend Engineer

Frontend Software Engineer

Full Stack JavaScript Developer

JavaScript Team Lead

Кто такой фронтенд

Есть бэкенд — это тот, кто про­грам­ми­ру­ет сер­вер­ную часть при­ло­же­ния. И есть фрон­тенд. Вот зачем он нужен, в чём его сила и сколь­ко мож­но тут зара­бо­тать.

Фронт? Бэк?

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

А отку­да эти дан­ные при­ле­те­ли? Кто ска­зал сай­ту выве­сти вам имен­но этот текст и имен­но эту кар­тин­ку?

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

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

Как в вакансии

Фронтенд-разработчик дела­ет сле­ду­ю­щее:

• соби­ра­ет сайт по маке­ту дизай­не­ра;
• исполь­зу­ет для это­го HTML, CSS, JavaScript и несколь­ко дру­гих язы­ков;
• пони­ма­ет про­цес­сы, кото­рые про­ис­хо­дят во вре­мя созда­ния сай­та;
• зна­ет, как опуб­ли­ко­вать сайт в Сети так, что­бы он выгля­дел оди­на­ко­во на всех устрой­ствах;
• уме­ет рабо­тать с Git или дру­гим инстру­мен­том кон­тро­ля вер­сий;
• исполь­зу­ет Webpack для сбор­ки про­ек­та и вооб­ще опе­ри­ру­ет пре­про­цес­со­ра­ми.

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

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

Фронтенд — это повар

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

Начало работы

Когда пова­ру дают новый рецепт, он гово­рит: «Хм, мне пона­до­бит­ся лук, мор­ковь, кар­то­фель и пара тома­тов. А ещё глу­бо­кая кастрю­ля, вен­чик для взби­ва­ния и ско­во­ро­да с тол­стым дном».

Фрон­тенд берёт макет со сло­ва­ми: «Так, это всё, конеч­но, хоро­шо, но кро­ме HTML и CSS тут нуж­но будет исполь­зо­вать Ajax для отправ­ки форм и JavaScript, кото­рый помо­жет отсле­дить нажа­тие на кар­тин­ку. Зна­чит, под­клю­чим вот эту и эту биб­лио­те­ки».

Использование технологий

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

Фронтенд-разработчик тоже не пишет весь код с нуля. Если он пони­ма­ет, что какую-то часть логи­ки будет слож­но реа­ли­зо­вать на стра­ни­це, то может отпра­вить её на сер­вер, что­бы все вычис­ле­ния были там. В ито­ге фрон­тенд попро­сит ребят на сер­ве­ре сде­лать такую-то функ­цию, кото­рая будет обра­ба­ты­вать дан­ные со стра­ни­цы — точ­но так же, как повар зака­зы­ва­ет гото­вые кор­зин­ки.

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

Рабочие инструменты

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

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

Глав­ное в рабо­те фрон­тен­да — пони­мать, как устро­е­ны и как рабо­та­ют тех­но­ло­гии, что­бы при­ме­нять их в про­ек­те.

Тонкости работы

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

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

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

Что дальше

Даль­ше всё оче­вид­но — нуж­но про­бо­вать. Спе­ци­аль­но для это­го в Яндекс.Практикуме дают 20 бес­плат­ных часов обу­че­ния фронтенд-разработке. Если понра­вит­ся — про­дол­жи­те и осво­и­те новую про­фес­сию.

Если бы я учил Frontend сегодня. Советы начинающим / Хабр

Мой путь в веб-разработке начался 5 лет назад. За это время я успел испробовать множество технологий, а в последние 3 года развиваюсь в направлении frontend.

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

Итак, ты хочешь стать Frontend разработчиком. Что для этого нужно?

HTML и CSS

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

С помощью HTML мы можем добавлять и описывать эти элементы. Изначально они будут «сырыми», со стандартным внешним видом. Для изменения стиля используется CSS. Он позволяет задавать цвет, размер, расположение и десятки других параметров внешнего вида элемента.

Как освоить

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

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

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

Где брать идеи и макеты для верстки?

Я использовал Dribbble и CollectUI, но также можно поискать на Behance и One Page Love.

Также можно брать настоящие макеты из UI Store Design. Я советую верстать макеты из Figma, т.к. её используют многие дизайнеры, и в будущем ты вероятнее всего будешь работать именно с ней. А еще она бесплатна и работает в браузере.

JavaScript

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

Если с HTML и CSS мы верстали страницу, то JavaScript отвечает за динамическую часть страницы: анимации, отображение данных, обработка действий и многое другое.

Зачем мне он нужен?

Простой пример. Предположим, есть страница, на которой по нажатию кнопки нужно отобразить модальное окно. HTML и CSS позволят нам сделать верстку самой страницы и модального окна. Однако зафиксировать и обработать нажатие на кнопку эти технологии не могут.
Здесь нам и нужен JavaScript. С помощью него мы описываем поведение на странице. В коде мы обозначаем: если пользователь нажал на кнопку, то нужно показать модальное окно.

Вот пример такой реализации и использованием JQuery:

С помощью JavaScript можно производить практически любые операции со страницей. Однако его возможности не ограничиваются окном браузера. С помощью платформы Node.js этот язык можно использовать для серверной разработки, сборки проектов, и многого другого. В будущем тебе это будет нужно, чтобы работать с большими проектами, собирая из через Webpack. Однако я советую сперва научиться использовать язык внутри браузера.

Как освоить

Лучше всего будет начать изучение на learn.javascript.ru. Это прекрасный ресурс, который является базой знаний как для новичков, так и для продвинутых разработчиков.

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

Не стоит слишком увлекаться одной лишь теорией JavaScript. Я рекомендую параллельно с изучением пробовать свои силы и писать простые скрипты. Можно также пробовать разбирать чужие участки кода на Codepen.

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

По большому счету, ты часто будешь прибегать к использованию сторонних библиотек в своих проектах. Чтобы лучше понять, как это делается, рекомендую попробовать форматировать даты с помощью Luxon или сделать карусель через Owl Carousel.

Что дальше?

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

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

Рекомендую ознакомиться с Frontend Roadmap. Здесь описаны технологии разработки интерфейсов, которые будут нужны тебе в дальнейшем.

В дальнейшем тебе наверняка будут интересны реактивные фреймворки, вроде React или Vue. Для сборки приложений на них ты освоишь Webpack, а для ускорения процесса верстки изучишь препроцессоры PUG и SASS. Или может быть захочешь углубиться в графику и научишься работать с D3 или WebGL.

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

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

Как стать тимлидом фронтендеров и как жить после этого — расшифровка эфира

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

Меня зовут Илья, я работаю в компании Яндекс.Деньги и руковожу фронтендом. До этого был бэкенд-разработчиком, писал на C#, около 5 лет назад перешел во фронтенд. Чуть больше года руковожу. Вот такой путь развития. Еще активно участвую в Burning Lead – это сообщество для ведущих разработчиков, тимлидов, людей, которые так или иначе пересекаются с задачами управления; надеюсь, ребята из сообщества слушают стрим.

Про Node.js и его использование

Сначала скажу, как она у нас появилась и почему мы ею пользуемся. Исторически сложилось так, что у нас в Деньгах есть полноценный Java-бэкенд, в котором Java-разработчики работают с базами данных, с основной бизнес-логикой. Фронтендеры с бизнес-логикой не работают, мы подготавливаем для себя нужный формат данных и отправляем его на фронтенд, а там уже рисуем их на каком-либо фреймворке. Изначально у нас был Xscript-сервер, который ребята в Яндексе сделали еще в 2000-х годах – это наше legacy. Часть логики – серверный рендеринг – мы писали на XML, XSL/XML преобразования. Так продолжалось очень долго. Потом, когда мы осознали, что разработчиков на XSL/XML стало тяжело искать, мы стали выбирать новый сервер, в который можно было бы писать на бэкенде и потом использовать на фронтенде. Оказалось, что есть целая платформа Node.js.

Тогда Node.js была очень молодой платформой, версия 0.10, наверно. Решено было использовать ее по нескольким причинам: язык Javascript набирал популярность, разработчиков было много; кроме того, серверную и клиентскую логику мог писать один разработчик без суперспецифичных знаний. О своем выборе мы не жалеем: платформа все еще активно развивается, оптимизируется, становится быстрее, получает полезные фичи, имеет активное сообщество.

Поговорим про архитектуру фронтенда и о том, чего мы хотели бы достичь в архитектуре Яндекс.Денег в целом. Так как мы используем Node.js, у нас уже долгое время основой серверного фреймворка служит Express. Он хорошо справляется со своей задачей – обрабатывает запросы пользователя и дает ответы, больше от него ничего не нужно. Для него написано множество плагинов. Есть SSR для React-приложений, например; так как основной стек на клиенте – это React, SSR не проблема прикрутить. Есть много реализаций; можно даже не писать код: разворачиваешь из NPM, он сам все делает.

Что касается архитектуры – мы порядка 4-5 лет живем на Express, и из-за этого возникают некоторые проблемы. У нас довольно много разработчиков – в отделе сейчас человек 50 – и нам нужно писать понятный для всех код; разработчики могут менять интересы, переходить из команды в команду, и нам нужно, чтобы код был примерно одинаковым, чтобы разработчик в новой команде не тратил по месяцу на акклиматизацию к новому коду. Express – довольно низкоуровневый фреймворк, и с ним живется довольно тяжело: каждая команда использует свое видение того, как писать обработчики запросов или бизнес-логику, ходить в бэкенд. Первая попытка наладить архитектуру сервера была совершена, когда мы сделали ProcessFlow. Я на эту тему выступал с докладами – рассказывал, как на основе IDEF0 можно построить систему, которая позволит организовать бизнес-логику, задать правила ее написания, сделать поддержку, визуализацию связей между сущностями. Попытка была вполне успешной: в некоторых местах у нас были серьезные проблемы с пониманием кода, и ProcessFlow помогла их решить. Она работает и сейчас, и вполне нас устраивает.

Сейчас у нас идет переезд на NestJS. Это довольно современный серверный фреймворк, позволяет писать контроллеры в парадигме Model-View-Controller, организовывать бизнес-логику; его философия пришла из Angular. Его сильная сторона – это правила, они уже на уровне фреймворка определяют написание контроллеров и бизнес-логики. Бесконтрольная среда бывает губительна, когда вас много и все пишут по-разному; лучше иметь свод правил, к которому всегда можно обратиться – такой путь мы выбираем. Про NestJS активно рассказывает мой коллега Андрей Мелехов, ведущий подкаст devSchacht; он сейчас описывает процесс переезда на NestJS, обсуждает проблемы.

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

Про клиентскую часть

Она состоит из двух больших стеков. Первый – это легаси-стек с использованием методологии BEM Naming (определенные названия CSS-стилей, позволяющие избегать пересечений), на основе которой в Яндексе создали фреймворк. Мы использовали его довольно долго, так как мы используем технологический стек Яндекса. Он классный, и в нем работа с компонентами организована примерно так же, как в современных фреймворках: в виде отдельно лежащих блоков, которые удобно поддерживать. Однако он уже устарел, поскольку основан на GQL и не отвечает современным требованиям по UI; на нем очень сложно делать анимации и приложения на клиенте. Мы постепенно переходим на React уже несколько лет (переход продвигается тогда, когда меняется дизайн или функциональность: то есть, все переписывания бизнес-процессов происходят на новой технологии). Он показался нам довольно мейнстримовым — то есть, разработчиков на нем много. React — основной фреймворк на клиенте, в качестве стейт-менеджера используется Redux; с ним же мы используем Redux-Thunk для асинхронных действий и запросов к бэкенду. В нескольких проектах использовали hooks.

Почему не Angular?

Когда мы выбирали стек, Angular был приблизительно версии 1.5. Он показался нам сомнительным, и мы выбрали другое решение. К последним версиям Angular я не имею претензий, но отказываться от React мы не хотим.

Как я стал тимлидом, почему я выбрал этот путь, какие плюсы и минусы

На самом деле, в каждой компании будут собственные требования к тимлиду или руководителю отдела, но, как мне кажется, есть и определенный план того, что нужно знать и делать, чтобы развиваться в направлении менеджмента. Есть такой подкаст – PodlodkaPodcast, они публиковали такой план (роадмап). Крутая штука; там написано, что следует читать для развития нужных softskills — на них нужно делать упор. Конечно, у хорошего тимлида должны быть и отличные hardskills: он – не просто формальный лидер команды (допустим, 5 человек), он должен доказать свое лидерство, он должен учить свою команду, его люди должны желать научиться программировать так же, как может он. Но важны и softskill: коммуникативные навыки для общения в пределах команды и вне их, для отстаивания мнения команды, для поиска компромиссов. В работе тимлида очень много коммуникаций. Кроме того, нужно уметь проявлять эмпатию: при общении с разработчиками важно устанавливать понимание на уровне чувств, понимать настроение каждого собеседника, определять, чего он хочет. Напрямую это не говорится, но очень хорошо, когда тимлид владеет этим. Здорово, когда к hardskills также прилагается умение наставничества: за таким тимлидом потянутся люди, он будет в состоянии четко формулировать и ставить задачи.

У меня все произошло приблизительно по этому плану. Я учился коммуникации, помогал ребятам – даже в тех случаях, когда я сам изначально не понимаю, в чем проблема, полезно вместе сесть и разобраться с проблемой. Ко мне стали чаще обращаться люди; руководство это заметило, и меня повысили до старшего разработчика, а через год – до ведущего. В нашей компании это – тот разработчик, который непосредственно отвечает за развитие и рост команды. Я готовил много различных воркшопов по тестам, нагрузочному тестированию. В общем, я смотрел, какие темы в отделе в данный момент «больные», и старался сделать что-то полезное для команды, чтобы улучшить положение – с помощью воркшопов, выступлений, просто личной помощи; и, когда наш руководитель ушел, он порекомендовал меня на его место.

Когда я стал тимлидом, проблемы только начались. Можно подумать, что на этом месте всё должно быть хорошо: разработчики работают, лид командует, и всё — но это не так. Когда я был разработчиком, я делал понятную задачу и радовался своему достижению – но у руководителя, как оказалось, задачи часто сильно размыты. Нужно «улучшить что-нибудь». Например, надо ускорить время код-ревью: человек заходит, просматривает код и нажимает кнопку, что тут можно улучшать? Второй важный момент, который на тебя давит, состоит в том, что руководитель не решает прикладных задач своими руками. И тут происходит «синдром самозванца»: может казаться, что ты просто тратишь время, пока разработчики пишут код, и ты иногда чувствуешь себя бесполезным. Нужно понимать и знать свою ценность: коммуникации – это тоже важная задача. Хороший руководитель помогает снять ненужные коммуникационные барьеры в ходе проекта; разработчики могут не коммуницировать, потому что им это некомфортно, но руководитель – обязан.

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

О процессах управления людьми в нашем отделе

Процесс разработки подразумевает общение разработчиков между собой, и у нас есть несколько точек пересечения. Задача на разработку поступает в одну из команд; обычно команда — это Java-разработчики, фронтенд-разработчики, менеджер, продукт, обязательно тестировщики. Такая единица, сидит где-то отдельно. Существование других команд для нее особенного значения не имеет само по себе – но нам необходимо, чтоб все команды писал приблизительно единообразный код. Для этого нужно общаться, и здесь есть несколько подходов. Во-первых, это происходящие время от времени встречи всего отдела; сейчас мы все собираемся в zoom, но это, конечно, не то. На встречах мы делимся новостями, ребята рассказывают, что они делают у себя в командах: какие у них проекты, какие будут в дальнейшем, что и как они делают. Это помогает строить представление о том, что происходит во фронтенде: он большой, просто так его рассмотреть не выйдет. Еще мы организуем tech talks, разные по масштабам: на всю компанию или на наш отдел, и там представляются технические приемы: например, на одном из них рассказывали, как используются hooks в React, как они влияют на форму, как выглядит код для них, какие плюсы и минусы. Такие доклады интересно слушать, и они помогают распространять по компании знания.Непосредственно в разработке есть процессы, которые позволяют нам общаться так, чтобы писать код, который потом не встретит непонимания на кодревью из-за используемых приемов, компонентов и библиотек – то есть, мы стараемся нивелировать плохие последствия от изолированного принятия решений. Этот процесс, который мы называем Logic Review, позволяет нам узнавать мнения экспертов, ведущих разработчиков, старших разработчиков после того, как мы понимаем, как делать определенную задачу – то есть, сверить наше видение реализации проекта с видением тех, кто определяет дальнейшее развитие всего отдела. Он позволяет нам обмениваться знаниями, технологиями, и контролировать однородность и архитектуру стека. Конечно, успеть везде и избежать всех проблем на кодревью невозможно, но такая сверка перед началом разработки позволяет уменьшить их количество.

Можно ли обмануть Review 360?

Напомню, что Review 360 – это когда все (разработчики, тестировщики, менеджеры), с кем работал человек, которого нужно оценить, опрашиваются «по кругу» с помощью опросника. Я об этом процессе рассказывал на Burning Lead. Если команда небольшая, как у нас обычно – человек 5-10 – то этот процесс, собственно, не нужен: тимлид может сам пообщаться с каждым членом команды. Собственно, он и должен общаться с каждым разработчиком раз в 1-2 недели, чтобы понимать, чего хочет разработчик, какое у него настроение, доволен ли он задачами, как он работает, как проходит его рост. Но, когда команда большая – например, у меня сейчас больше 50 фронтендеров – то на такое личное общение уже не будет хватать времени. У тимлида есть и другие обязанности и проекты, он обязан развивать отдел, он не может тратить все рабочее время только на общение, которое впоследствии нужно будет еще и проанализировать. Поэтому приходится использовать менее точные подходы – например, Review 360.

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

В целом, я думаю, что 360 Review – довольно объективная вещь, и мы их проводим с определенным промежутком времени. Опыта по ним накопили еще не слишком много, но мы постепенно двигаемся вперед и совершенствуем методы подсчета статистики и наборы вопросов.

Расскажите про менеджер зависимости, composer и Laravel

Я знаю, что Laravel – хороший PHP-фреймворк, и у нас на нем пишут, но сам с этими технологиями почти не работал.

У вас есть разделение на верстальщиков и JS-разработчиков, или разработчик делает все?

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

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

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

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

Про архитектуру я уже немного рассказывал. Библиотека компонентов у нас есть, их несколько. Есть та, которую мы получаем от Яндекса, чтобы визуальный стиль был одинаковым. Есть дизайн-система, которая говорит, какие сетки, цвета, типографику (и т.д.) мы используем на фронтенде – то есть, эта система полностью диктует расположение и цветовую схему. Наконец, библиотека общих между приложениями компонентов, которые мы используем. Приложений у нас больше 20 (26?), и во всех она используется; иногда мы довольно сильно ползем по версиям – получаются разные версии в разных приложениях, из-за чего может страдать визуальная часть. Это одна из больших проблем устройства микросервисов с общей библиотекой, но мы стараемся.

Какой размер вашей команды?

У меня две роли в компании: я руковожу отделом порядка 50 человек и одновременно являюсь product owner нашей платформенной команды, там 8 человек.

React Native или Flutter?

У нас были эксперименты с React Native, Flutter тогда был очень новым; мы решили, что выберем React Native.

Яндекс хочет свой фрейм запускать?

Нет, BEM – это очень старый фреймворк, он устарел, мы вместо него используем React. Никто не хочет запускать новый фреймворк.
Вопрос: на бэкенде только JS, или есть какие-то legacy-части?
Я рассказывал, что у нас есть сервер с Xscript с XML/XSL. Это как раз и есть наше legacy, мы его активно выпиливаем и хотим как можно скорее прекратить его использовать. В основном – в 96% случаев – у нас используется JS.

Redux-Thunk или Redux-Saga?

Мы использует Thunk. К Saga был подход; может быть, у нас тогда просто не было ребят, которые достаточно хорошо в ней разбираются, но преимуществ над Thunk мы не увидели. Сейчас уже есть подход с hooks, но пока Thunk очень активно используется.

Вы внутри компании или команды ставите задачи по Smart?

Когда мы делаем проекты, цели ставятся по Smart. То есть, мы должны четко представлять, что мы будем делать и к чему прийти. Новичкам тоже задачи ставятся по Smart. Но я не могу сказать, чтобы уже в процессе разработки всегда были четко прописанные задачи: часто, когда ребята в команде создают задачи, они могут быть совершенно по-разному описаны, но для новичков всегда всё описывается так, чтобы было ясно, как идти и к чему. То есть, не все 100% задач ставятся по Smart, но мы активно используем эту методологию.

Насчет микросервисов – сейчас выкатили Module Federation Pack 5, можно ли в эту сторону посмотреть?

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

В чем разница в управлении 5, 10 и 50 людьми?

Во внимании, уделяемом разработчикам. Когда разработчиков 5-10, я могу с каждым из них пообщаться, выслушать проблемы, понять, чего они хотят и как развиваются. Когда их 50, это невозможно; конечно, это ухудшает ощущения от роли руководителя, потому что кажется, что я отделен от разработчиков, но сделать с этим ничего нельзя. Это основная разница. Кроме того, 5-10 человек – это одна команда, которая вместе работает, но 50 человек не могут быть одной командой; такое количество разработчиков нужно разбивать по отдельным управляемым группам, иначе не получится держать фокус.

Будет ли массовый переход на NestJS?

Сложно сказать. Может, завтра появится новый фронтенд-фреймворк, превосходящий NestJS, и мы все будем на него переходить. Я думаю, что сейчас NestJS хорошо проработан, но нужно исходить из задачи. Для многих задач, которые мы решаем на Node, не нужен такой серьезный фреймворк – например, для лямбда-функций, которые кто-то будет вызывать; но, когда на фронтенде есть развесистая логика, кажется, что подошел бы лучше Nest. Он сейчас хорошо проработан, есть и бэкенд-фреймворк (хотя он был довольно сырым, когда мы смотрели его). Nest развивается и, может быть, станет более популярным, но я не думаю, что будет массовый переход на него, как на Express.

Чем отличаются собеседования на джуна и миддла? Что оценивается во втором случае?

Когда мы собеседуем джуна, мы проверяем мотивацию человека, базовые знания JS, смотрим на коммуникативность и желание развиваться. С миддлом все интереснее: ведь миддлы – это люди, которые пишут основную часть кода наших проектов; у них мало встреч, они большую часть времени именно разрабатывают. Мы должны хорошо проверить его hardskills (задачами), узнать, как он рассуждает, поговорить про архитектуру, спросить, как он организует проекты, рассмотреть его стиль написания кода. У самого миддла уже есть сформированные ожидания относительно компании – то есть, с нашей стороны нужно донести, чего мы ждем от него и что можем предложить.

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

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

Как строите процесс по управлению таким количеством человек? Сколько лидов? Тяжело ставить цели?

Непросто. Очень много коммуникаций. Вместо официальных лидов у нас в каждой команде роль лидера выполняет самый опытный разработчик, который непосредственно работает и общается с людьми, проводит ревью, декомпозирует и нарезает задачи. С каждым таким лидом мы коммуницируем, пересекаемся на ревью. Есть еще более крупные направления (B2B, B2C), и у каждого направления есть человек, который за него отвечает. Он выстраивает работу в своем направлении, в том числе работу с людьми. Я стараюсь общаться как со старшими разработчиками, так и с ведущими разработчиками направления, как можно чаще; еще у нас есть общие встречи старших разработчиков, где мы обсуждаем новости, проблемы команд и процессов, думаем, что делать. Я думаю, старшие разработчики должны ощущать себя некоторой командой, с которой можно свернуть любые горы – сделать процессы такими, как нужно, вместо того, чтобы смиряться с неудобствами.

Проводите 1 на 1? Как часто? Лайфхаки?

Собственно, у нас в компании ревью как раз называется «1 на 1». Сейчас я провожу со всеми старшими разработчиками ревью раз в месяц (это реже, чем рекомендуется – лучше проводить раз в пару недель). Зачастую нам есть, что обсуждать. Лайфхаков особых нет – в литературе достаточно подробно расписано про 1 на 1. Важно давать разработчику говорить – он должен говорить примерно 80% времени; в этом суть: задача руководителя – создать на ревью дружественную и безопасную атмосферу, чтобы разработчик мог ему рассказать все, что его беспокоит. Это довольно тяжело и не всегда получается, но круто, если 1 на 1 есть, и на них есть, что обсуждать. Их лучше проводить в неформальной обстановке – например, можно в парке. Создание комфортной атмосферы может быть разным – это не только переговорка в офисе.

Какие вакансии у вас открыты?

В каком направлении? У нас довольно много в разных направлениях. По фронтенду мы ищем нескольких миддл-разработчиков (по-моему, 2), можно и senior.

Какие сложные задачи возникают у руководителя?

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

Рассматриваете фронтов на удаленке?

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

Что делать, если тимлид слабоват и явно не должен оставаться на позиции?

Нужно использовать механизм подачи обратной связи. Это мощный и классный механизм, но, конечно, нужно делать это аккуратно, чтобы человек не обиделся. Нужно уметь проявлять эмпатию, понимать чувства человека, давать в правильном направлении обратную связь. Он может либо принять, либо не принять ее; если он стал тимлидом, он должен уметь работать над собой и принимать обратную связь. Важно не просто дуться на него из-за того, что он «не дотягивает», а сказать ему конструктивно, что, на ваш взгляд, делается плохо, и узнать его мнение. Я сам не мастер подачи обратной связи, мне еще предстоит этому научиться, но я знаю главное правило: говорить про действие, а не про личность. Если рассказать лиду, какие вещи в команде проседают – может быть, все починится.

А что дальше?

30 июня в 20:00 в нашем инстаграм-аккаунте будет выступать Влада Рау — Senior Digital Analyst в лондонском офисе McKinsey Digital Labs. Сейчас Влада занимается product/data engineering. До своего переезда в Лондон она дважды стажировалась в Google в Дублине, а также училась в ВШМ СПбГУ и IE Business School в Мадриде.

Задать ей вопрос можно в комментариях к этому посту.

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, технический директор и основатель DeviceLock — кто ворует и зарабатывает на ваших персональных данных.

Как выжить и стать frontend разработчиком в современном мире? / Хабр

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

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



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

Рис.1 — Весь секрет успеха просто в трех мониторах.

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

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

Конечно многие могут поспорить с тем, а нужны ли алгоритмы или какие-то паттерны во фронтенде, но современные реалии диктуют свои жесткие условия. Многие пытаются сразу же приступать к изучению популярных javascript фреймворков, таких как angular или react не понимая того, что делают. Все это можно сравнить с человеком, который идет в темном туннеле на какой-то свет. Но не очень понятно, к чему этот свет приведет и что вообще там дальше. Гораздо лучше, когда ты знаешь какие подводные камни тебя ожидают в этом туннеле и что у тебя под ногами. И вообще, из чего состоит этот туннель и нужно ли по нему идти. О чем это я? А о том что зная основы программирования, алгоритмы, понимая паттерны проектирования , ты будешь понимать, что «под капотом» у того или иного фреймворка, какие у него есть подводные камни, стоит ли вообще обращать на него внимание. Вот с этого и нужно начать свой путь. На это и нужно обратить свое внимание в самом начале.

Где приткнуть голову?

Далее есть несколько вариантов развития событий. Какой из них лучше — решать вам.

• Школа программирования. Отличное решение для старта вашего развития. И если в курс обучения будут входить вышеописанные вещи, это будет плюсом вам в карму. Но не ожидайте чуда. Потому что за вас никто не будет писать код и составлять алгоритмы. Все, что вам предоставят — это нужную подачу информации, которая будет уже отобрана специально для вас. Еще одни большим плюсом являются практические уроки с ментором. Когда на все твои вопросы ты моментально получаешь наглядный ответ. Всегда стоит задуматься над таким вариантом старта, но при этом держа в голове мысль о том, что нужно самому очень много работать. Все что вам предоставят — это материал и менторство. Минус является то что зачастую весь курс обучения очень растянут и то что можно выучить за месяц можно учить за четыре, а то и полгода, хотя может для Вас это будет наоборот плюс?
• Онлайн курсы. Очень интересный выбор. Большинство таких онлайн курсов проходят в виде интенсивов. Здесь тоже есть личный ментор и даже домашнее задание, а по окончанию курса обязательно парочка выполненных проектов в портфолио. О том, сложно ли найти хорошие онлайн курсы, я умолчу. Есть из чего выбрать.
• Самоучка. Наверное, это один из лучших вариантов развития событий, но не для каждого. Очень прекрасно, когда ты самостоятельно разобрался с материалом, усвоил его и закрепил на практике. От этого можно получить очень много профита и зачастую работодатели ценят такие кадры. Выбрать из мусора алмаз это еще нужно уметь, и если у вас есть в кармане такой навык, вам очень повезло и вы быстро будете расти как специалист. При таких раскладах курсы не нужны, разве что, для того чтоб стать совсем «скилловым». Не открою большой тайны если скажу что в большинстве курсов и видеоуроков малой и средней ценовой категории используют материалы из современных книг программирования. Советую обратить на это внимание и возможно вы не потратите деньги впустую. А знания при прочтении хотя б одной такой книги с пониманием — будет более чем глубокими.
• Стажировка в компании. Здесь дают возможность окунуться в сферу IT с ног до головы. Но не каждому выпадает такая возможность, а только тем у кого уже есть какой-то багаж знаний за плечами. Будьте готовы выполнять тестовые задание, чтоб попасть на стажировку. Но оно того стоит, это прямой путь к приему на работу.

Итак, что выбрать решать вам. А что далее? А далее происходит самое интересное. Работа.

Ожидание. Реальность

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

С чего начать поиск работы

Для frontend разработчика незаменимая вещь для трудоустройства являться его портфолио. Мало того что вы делаете свой реальный проект так вам еще и будет что показать работодателю. Это очень хорошая практика, и после изучения материала сразу же к ней нужно приступить. Здесь и можно «понюхать порох». Если вы добавите в свое портфолио несколько личных проектов, то считайте что вы обречены на успех. Но не нужно надеяться что все так легко, открыв некоторые вакансии понимаешь что еще учиться лет 10 для уровня «Джуна». Порой компании требуют знания языков С++, PHP и С# вместе на позицию верстальщик. Да, и такое бывает. Наверное они просто в поисках разносторонних личностей.

Вернемся во frontend

И вот вы junior frontend developer, сделав портфолио, впервые заполнив свое резюме вступаете в новый челлендж «выжить любой ценой». Angular, React, Redux, Vue.js, EcmaScript 6 и проч. С каждым годом требования к специалисту все больше и больше. И понять на что обращать внимание очень сложно. Для некоторых компаний будет достаточно знаний JavaScript, для иных нужен полный стэк технологий. На все это не нужно обращать внимание если у вас есть цель. Цель стать хорошим разработчиком. Крепко зная основу, вы сможете овладеть любым современным фреймворком и это главное. Не нужно привязываться к контексту. Каждый фреймворк имеет свой срок и нужно это понимать. Если вы бросите все силы на изучения React а через несколько лет процент его использования будет очень близко приближен к нулю то что тогда делать? Зная и понимая как все устроено «под капотом» вы будете всегда на высоте. Главное не сдаваться и терпеливо идти к своей цели..

Чем отличается верстальщик от front-end developer? — Хабр Q&A

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется «толстый клиент»), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

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

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

————

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front…

Что фронтенд разработчики должны знать о бэкенде? / Хабр

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

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

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

Частота запросов

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

Как мы можем измерить насколько запрос затратный?

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

Давайте рассмотрим пример того когда это становится критичным: предположим мы разрабатываем google docs.

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

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

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

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

Время простоя (downtime)

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

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

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

В любом случае, хороший фронтэнд должен всегда отлавливать ошибки в запросах с помощью try catch и иметь заготовленные ошибки для пользователя. В javascript нет встроенной функции(recovery panic), которая позволяет продолжить выполнение кода после ошибки, поэтому при её возникновении ваше приложение упадет.

HTTP

Бэкэнд и фронтенд должны использовать соответствующие HTTP статусы (в определенной степени). Надеюсь, ваш бэкэнд не воспринимает каждую ошибку как 400.

Интерфейс должен знать каждый статус, который бэкэнд планирует вернуть.

Не парсите сообщения об ошибках, чтобы определить, то что авторизация не удалась, код ошибки 401 подходит для этого больше.

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

Другие свойства HTTP запросов которые желательно знать:

• HTTP запросы могут быть закрыты сервером если они занимаются слишком много времени прежде чем завершатся. Если вы думаете что некоторая задача займет больше времени чем лимит на запрос (как правило около 20 секунд), вам следует выбрать вместо единичного запрос-ответа, запрос с последующим опросом результата. Или воспользоваться другими механизмами, например веб-сокетами.
• Если вы отправляете большое количество данных на сервер(например видео), вы должны использовать составной HTTP запрос(multipart/form-data), который делит данные на части перед отправкой.
• Иногда неожиданно возникает то, что существует ограничение размера URL. Некоторые веб-интерфейсы передают данные обратно на сервер с query параметрами, но если они длиннее 2048 символов, вам придется изменить такой способ на передачу параметров в теле HTTP запроса.

Делегирование бизнес логики

Если какая-то бизнес логика вашего функционала может быть реализована и на бэкенде и на фронтенде, где лучше её реализовать?

В основном лучше делать это на бекенде. Причины:

1. Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
2. Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
3. Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для pro пользователей. Если ограничение будет сделано на фронтенде, то кто-либо потенциально может провести реверс-инжиниринг и получить доступ к функционалу.

Кросс-доменные запросы

В качестве протокола безопасности, если запрос к бэкэнду поступает из другого домена, он будет отклонен из-за того что он является кросс-доменным запросом. Такое поведение обусловлено политикой одного источника(Same-Origin Policy). Данная политика запутывает людей в процессе разработки, поскольку порты тоже считаются частью домена.

Зачастую используется сервер npm/yarn для фронтенда и бэкенда на другом порту, что делает каждый запрос кросс-доменным.

Решения:

• Указание одного домена в hosts файле и разграничивание фронтенда и бекенда с помощью nginx*.
• Включить кроcс-доменные запросы на сервере в зависимости от переменной среды, если production то false, если development то true.
• Включить домен с которого ведется разработка в белый список исключений.

Межсайтовая подделка запросов(CSRF) — так называется атака, которая делает несанкционированный запрос от пользователя инициированный с другого сайта.

Например: вы нажимаете кнопку на каком-либо сайте и он выполняет javascript код, который попытается выполнить запрос на сайт вашего банка.(подробнее)

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

Очистка кэша

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

Веб-приложение загружается быстрее чем в первый раз, поскольку браузер кэширует ресурсы, такие как favouritewebsite.com/static/script.js.

Что если вы хотите внести изменения в script.js? Вы меняете имя файла. Допустим, вы меняете script.js на script.js?v=2, на который ссылается index.html.

Закэшированный script.js становится неактуальным, поскольку к нему никогда не будет другого запроса (если сам index.html не будет закэширован! Запрос к index.html должен быть инвалидирован на бэкэнде).

Современные конвейерные сборки включают в себя очистку кэша для каждой сборки, поэтому большинство javascript файлов выглядят как script.4e885f13.js. Обычно это применяется только к css стилям и скриптам, но вы также можете применить их к изображениям и другим ресурсам.

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

*Примечание переводчика:

В оригинале было так:

Map your server domains to some hostname in your dev environment’s host config.

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

Что такое Front End Testing? Инструменты и платформы

• На главную

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • 0005 9000 J5000 J5 9000 J5000 9000 9000 J5
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM) So
    • RPA

    000

    • SAP4 Testing

    000

    000

    • SAP4 Testing Management
    • TestLink

• SAP

  • • Назад
    • ABAP

    9 0004 APO

    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • FICO
    • MMO
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials
• AngularJS
• ASP.Net
• C
• C #
• C ++
• CodeIgniter
• СУБД
• JavaScript

• Назад
• Java
• JSP
• Kotlin
• Linux
• Linux
• Kotlin
• Linux

js

• Perl

• Назад
• PHP
• PL / SQL
• PostgreSQL
• Python
• ReactJS
• Ruby & Rails
• Scala
• SQL

000

0004 SQL

• UML
• VB.Net
• VBScript
• Веб-службы
• WPF