Frontend-разработчик: кто это, чем занимается и сколько зарабатывает? обзор профессии

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

Над созданием веб-ресурса работает целая команда. Наряду с веб-дизайнером, верстальщиком и SEO-специалистом трудится и frontend-разработчик.

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

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

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

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

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

Кроме этого, в основные обязанности входит:

1. Верстка дизайна веб-сайта. Цель этого этапа – создание структуры HTML-страницы, элементы которой будут совпадать с теми, что на макете дизайнера. Элементами могут быть кнопки, картинки, текст и т. д. Для работы понадобится не только HTML, но и CSS.
2. Регулирование функционала сайта: отладка кнопок, клавиш, форм для заполнения личных данных, полей для обратной связи, форм для комментариев, слайдеров, фотогалерей. Фронтенд может создать свою программу (скрипт) или взять готовую.
3. Проверка функционирования всех элементов интерфейса, их тестирование и доработка при необходимости.

Более 100 крутых уроков, тестов и тренажеров для развития мозга

Начать развиваться

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

1. Дает рекомендации и советы по поводу реализации и оптимального эксплуатирования определенной опции на сайте.
2. Оптимизирует скрипты, чтобы сайт стал загружаться быстрее.
3. Создает шаблоны для CMS.

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

Если хотите посмотреть HTML-код, который написал frontend-разработчик, нажмите “Ctrl+Shift+L”. Другой способ – нажать правой кнопкой мыши на пустом месте страницы и в появившемся окне нажать на “Посмотреть код”.

Эта деятельность требует умения владеть большим набором современных технологий.

Где обучиться профессии с нуля?

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

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

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

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

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

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

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

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

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

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

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

Что нужно знать начинающему front-end разработчику

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

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

Также начинающий front-end разработчик должен знать, где именно он может получить соответствующие знания и образование, подкрепленное дипломом. Во-первых, он может поступить в Международный учебный центр IT-образования «Компьютерная академия Шаг». Здесь только очное отделение, а выпускники получают соответствующие сертификаты и международный диплом. На сегодняшний день филиалы академии представлены в шестнадцати странах мира. Во-вторых, можно пройти онлайн-курсы в Образовательном IT-портале GeekBrains. За шестинедельный курс здесь можно пройти стажировку.

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

Очистка кэша

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

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

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

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

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

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

Чем дизайнер может помочь фронтенд-разработчику

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

История изменения макетов. Часто при работе над макетом неожиданно обновляются требования к продукту, и в макет вносят изменения. Фронтендщику ставят задачу на перевёрстку, но, на первый взгляд, все выглядит, как раньше. Только при более детальном исследовании выясняется, что поменялся, например, порядок иконок социальных сетей в футере, изменились некоторые отступы в контентной области или изменились некоторые тексты на странице. Чтобы это выяснить, приходится делать скриншот макета и сопоставлять его с текущей вёрсткой сайта. В Figma на данный момент нет системы контроля версий, поэтому всё ложится на плечи команды. И только коммуникация помогает решить данную проблему.
Стайлгайд проекта. Страница со всеми состояниями интерактивных элементов, страница с типографией, страница с формами и примерами их заполнения и прочее, что позволит атомарно подойти к блокам. Хорошо проработанный стайлгайд проекта —  залог успеха. Главное держать его в актуальном состоянии и не нарушать его.
Доступность интерфейса

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

Внедрение доступности будет гораздо тяжелее, если вообще возможно.
Детально проработанная адаптивность. Полное понимание, как будет вести себя макет при его сжатии и расширении. Это решит проблему с промежуточными состояниями между брейкпоинтами и упростит создание любого типа верстки.
Структура проекта в Figma. Многие разработчики жаловались мне, что невозможно открыть Figma, потому что на одной вкладке отображаются все страницы проекта. Правильная структура хранения проекта облегчит работу с ним как дизайнеру, так и разработчику.
Названия у цветов и шрифтов. Когда у всех цветов и типов шрифтов есть имена, фронтенд разработчику не придётся их придумывать. Идеально, если имена содержат только буквы, цифры и знаки «$» и «_», при этом первый символ не является цифрой. Это необязательно, но позволит использовать названия прямо в коде, что облегчит их применение и поддержку в актуальном состоянии.
Консистентность между версиями. Это, скорее, просьба к дизайнерам. Разрабатывая макет мобильной версии сайта, старайтесь помнить, что это всё-таки сайт, а не мобильное приложение. Хочется видеть консистентность между десктопной и мобильной версиями. В некоторых проектах мобильная и десктопная версии настолько отличались, что приходилось делать разные версии с нуля, а это забирает в два раза больше времени на разработку.

Эксперимент 1

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

Используя CodePen, вы убиваете двух зайцев сразу. С одной стороны вы практикуете HTML и CSS. C другой стороны вы создаете основу для портфолио с иллюстрациями вашего прогресса. Мы так же будем использовать Dribbble, который полон вдохновляющего дизайна.

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

Когда вы определились с дизайном, идите и попробуйте сверстать его на CodePen. Если вы застряли, помните что StackOverflow (англ.) ваш друг. Другой полезной практикой будет пойти на такие сайты, как Medium, AirBnB и Dropbox и при помощи инструментов разработчика (англ.) посмотреть как реализована разметка и стили. Так же взгляните на некоторые примеры на CodePen. Я прикрепляю несколько хороших ссылок:

• Меню приложения
• Виджет Twitter
• Простое плоское меню

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

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

Что насчёт общих типов?

• Если у вас есть монорепозиторий, то можно просто импортировать определение из generic path в оба проекта. Однако такой подход привязывает жизненный цикл ваших типов к обоим проектам одновременно, потому что внося изменение в файл (например, в определение типа), вы влияете на весь монорепозиторий. Да, хорошо владея git, вы можете обойти эти проблемы, но это немного трудоёмко.
• Можно превратить определение типов в модуль NPM, после чего установить в качестве зависимости в код фронтенда и бэкенда. Затем всё будет работать отлично, но на этапе начальной разработки вам необходимо будет опубликовать модуль, иначе у вас будут локальные пути импорта, которые придётся рефакторить в абсолютные. И даже после завершения начального этапа разработки любые изменения в локальной версии модуля типов нужно будет публиковать, иначе их не увидят другие проекты. Это может оказаться довольно хлопотным.

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

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

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

• Языки: HTML, CSS, JavaScript, всё чаще требуется TypeScript.
• Фреймворки: React, Vue или Angular. Нужно уметь работать с одним из них.
• Дополнительные инструменты: работа с внешними расширениями через NPM или Yarn, настройка сборки фронтенда (например, Webpack).

Рассмотрим типичную задачу младшего фронтенд-разработчика.

Предположим, у команды есть проект на React и TypeScript. В него нужно добавить компонент, выводящий на страницу иконку. Иконка может быть разных цветов в зависимости от ситуации, в которой она появляется:

‘primary’ — основной цвет,

‘secondary’ — вспомогательный цвет,

‘error’ — цвет в случае ошибки,

‘success’ — цвет в случае успешной операции.

Все цвета заданы в дизайн-системе. Связь названий и цветов описана в файле utils.ts. Выглядит он примерно так:

// utils.ts

type TIconTypes = 'secondary' | 'primary' | 'error' | 'success';

export type TIconProps = { type: TIconTypes, onClick?:() => void; };
export const getIconColor = (type: TIconTypes) => {

  return `${
    type === 'secondary'
      ? '#8585AD'
      : type === 'error'
      ? '#E52B1A'
      : type === 'success'
      ? '#00CCCC'
      : '#F2F2F3'
  }`;
};

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

// icon.tsx

import React from 'react';
import { getIconColor, TIconProps } from './utils';

export const Icon = ({ type }: TIconProps) => {
  return (
    <svg
      xmlns="<http://www.w3.org/2000/svg>"
      width="24"
      height="24"
      viewBox="0 0 24 24"
      fill={getIconColor(type)}
    >
      <path d="/* здесь будет длинный набор чисел, описывающих svg-изображение */"/>
    </svg>
  );
};

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

Это лишь небольшой пример задачи, но он наглядно демонстрирует необходимость понимания дополнительных технологий помимо HTML, CSS и JavaScript: например, React и TypeScript. То, какие технологии потребуются на конкретном проекте, определяет стек, принятый внутри команды или компании. Его нужно либо знать, либо быть готовым быстро в него погрузиться.

Как стать frontend-разработчиком? Что нужно знать и уметь?

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

1. Освоить HTML и CSS. HTML – это язык разметки веб-документов. CSS – каскадные таблицы стилей. Они управляют оформлением различных элементов на страницах (например, размером шрифтов).
2. Изучить JavaScript – основной язык, который нужно знать frontend-программисту. Существуют различные библиотеки готовых скриптов, написанных на JavaScript. Их тоже лучше изучить, чтобы пользоваться ими и ускорять свою работу. Пример такой библиотеки – jQuery.
3. Изучить методологию верстки, например, БЭМ от Яндекса. Методология помогает создавать веб-приложения по определенным принципам, которые помогают разбираться в чужом коде и в своем тоже по прошествии какого-то времени.
4. Изучить фреймворки, в частности, Bootstrap. Фреймворк – это набор неких готовых решений, на базе которых можно создавать веб-сайты быстрее, чем при написании кода с нуля.
5. Освоить кроссбраузерную верстку и научиться создавать страницы, которые одинаково выглядят в разных браузерах.
6. Изучить адаптивный дизайн, т.е. дизайн, который подстраивается под размеры экрана пользователя. Таким образом сайт приемлемо выглядит на разных устройствах (компьютер, планшет, смартфон).
7. Не лишним будет освоить языки серверного программирования на базовом уровне. Например, язык PHP – один из самых популярных в среде веб.

8. Изучить Git и научиться работать с системами контроля версий.

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

Фронт + бэк = фулстэк

Если в двух словах, то фронтенд (Front-end) — это сцена, бэкенд (Back-end) — закулисье, а фулстек (Full Stack) — их совокупность, то есть вся подготовительная работа к спектаклю и сам спектакль.

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

• Превращает макет дизайнера в код. Щелкните правой кнопкой мыши прямо сейчас, выберите «Исходный код страницы» — его написал фронтендер.

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

• Следит, чтобы информация корректно отображалась на разных устройствах. Если в мобильной версии все «поехало», это недочет фронтендера.

• Готовит данные к отправке на сервер или в сторонние приложения.

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

Бэкенд-разработчик отвечает за то, что скрыто от глаз пользователя, происходит вне его компьютера или другого устройства. Например, когда вы вводите запрос в поисковой строке Google или Яндекс, вы имеете дело с фронтендом, как только вы нажимаете Enter, в игру вступает бэкенд. Запрос уходит на сервер поисковика, распознается там и возвращается в виде понятного ответа. В выдаче появляется список сайтов — это снова фронтенд.

Коды для фронта и бэка пишутся на разных языках. Для первого наиболее актуальны HTML, CSS, JavaScript, для второго — Ruby, PHP, Python, Java.

Фулстэк-разработчик владеет сразу несколькими языками, отвечает и за «темную» серверную сторону, и за «светлую» пользовательскую. Иногда он также обладает компетенциями UI/UX-дизайнера. В общем, универсал.

Эксперимент 3

В рамках эксперимента 3 выберите один из прошлых экспериментов и проведите рефакторинг своего кода с использованием советов, которые вы узнали выше. Рефакторинг означает редактирование вашего кода так, чтобы он стал проще, в том числе в плане читаемости.

Умение проводить эффективный рефакторинг кода — очень важный навык для фронтенд-разработчика. Создание эффективного кода- постоянный процесс. Возьмите статью CSS архитектура: рефакторинг CSS (англ.) в качестве отправной точки для вашей работы над рефакторингом.

Не важно сделать правильно с первого раза. Важно сделать правильно в конечном результате

Ниже несколько вопросов, на которые вы должны себе ответить в процессе рефакторинга.

• Не двусмысленны ли названия классов? Через полгода я все еще смогу понять, что означает название класса?
• Семантичен ли мой HTML и CSS? Можно ли с первого взгляда определить структуру и взаимоотношения элементов?
• Использую ли я одни и те же цвета в коде? Не будет ли логичнее вынести их в переменные Sass (англ.)?
• Работает ли мой код в Safari так же хорошо, как в Chrome?
• Нельзя ли заменить часть кода на систему сеток, например Skeleton?
• Не слишком ли часто я использую !important? Как я могу это исправить?

Двигаемся к Модели приложения (Application model)

Вскоре стало понятно, что Application State не может быть полностью изолирован от GUI. Всегда существует какая-то логика представления (Presentation logic) или состояние представления (View state), которые необходимо поддерживать.

Но это может вызвать проблемы. Давайте возьмем наш предыдущий пример счетчика. Когда наш счетчик достигнет 10, мы должны изменить цвет метки с черного на красный, чтобы указать предупреждение. Такое поведение изменения цвета на самом деле не является бизнес-логикой или задачей. Это чисто эстетическая часть (UX), которая должна быть учтена. Настоящий вопрос — где? Это должна быть Модель или Представление?

Поскольку эта Логика представления или Состояние представления в основном представляет собой состояние, полученное из Модели предметной области, оно должно поддерживаться в Модели. Но Модель предметной области, поддерживающая визуальный аспект, — то есть красный цвет — по определению не очень хорошо. Если же мы поместим это в объект Представление, то это создаст еще один набор проблем. Наш виджет больше не является шаблонным. Мы не можем использовать его в другом месте. Кроме того, добавление условия с жестко закодированным числом 10 в наш объект View означает, что мы ограничиваем некоторую часть бизнес-логики.

Чтобы решить эту проблему, в исходную MVC была добавлена еще одна сущность — Модель приложения (Application Model, AM). Как видно на рисунке, с Моделью приложения пара View-Controller не имеет прямого доступа к модели. Вместо этого они регистрируются в событиях Модели приложения и используют его для доступа к необходимым данным.

Потоки данных остаются такими же, как и у классического MVC. Конечно, у каждой модели есть свои плюсы и минусы, и AM-MVC не исключение. Наиболее заметная проблема заключается в том, что Application Model не имеет прямой ссылки на объект View и, следовательно, не может манипулировать им напрямую, даже если Application Model предназначена для поддержания состояния View.

Важные личные качества

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

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

Прокрастинация — опасный враг бэкендера, он должен уметь сосредоточенно работать, иногда в крайне сжатые сроки, поэтому «пилить код с ленцой» это, пожалуйста, в пет-проект или уже в состоянии тимлида (там других задач хватает).
Логическое мышление и аналитический склад ума. Оно и понятно.
Умение доводить дело до конца, нацеленность на результат. В бэкенде важен результат — корректно и ожидаемо работающее приложение.
Способность переключаться на макрозадачах. Нередко бывает, что нужно оставить код одной части проекта и реализовать довольно крупную функцию. Это непросто, потому что программист уже погружён в архитектуру и логику. Способность переключаться без особых проблем для задач — практически джедайская. 
Навыки планирования и исполнения плана. Бэкенд любого проекта — это сборник разноплановых задач. И если вы единственный бэкендер проекта или у вас с коллегами слабо реализовано разделение труда, только планирование и спасёт от авралов, факапов и срыва дедлайнов. Жёсткое к себе и времени планирование — залог спокойной работы практически без переработок (которые у бэкендеров случаются чаще остальных).
Умение работать в команде. Вам нужно будет взаимодействовать с единой командой разработки единого же приложения, а значит, дискуссии, но не конфликты, рефакторинг, но не оскорбления, отстаивание своей позиции, но не бойкоты. Если злой интровертный бэкендер отлично сделает свою работу, закоммитит и умоет руки, его труд пользователи ещё долго не смогут оценить — потому что нужно «собирать» проект в составе всей команды, а не отгораживаться по принципу «к фронтенду ни ногой».