Фронтенд и бэкенд что это – Frontend разработчик – кто это, чем занимается, что должен знать? Как стать фронтенд программистом с нуля?

Простыми словами о «фронтенде» и «бэкенде»: что это такое и как они взаимодействуют

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

Давайте начнем с определений.

Фронтенд — все, что браузер может читать, выводить на экран и / или запускать. То есть это HTML, CSS и JavaScript.

HTML (HyperText Markup Language) говорит браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка».

CSS (Cascading Style Sheets) говорит браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana».

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

Бэкенд — все, что работает на сервере, то есть «не в браузере» или «на компьютере, подсоединенном к сети (обычно к Интернету), который отвечает на сообщения от других компьютеров».

Для бэкенда вы можете использовать любые инструменты, доступные на вашем сервере (который, по сути, является просто компьютером, настроенным для ответов на сообщения). Это означает, что вы можете использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript / Node, bash. Это также означает, что вы можете использовать системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Структура взаимодействия бэкенда и фронтенда

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

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).

Когда страница загружена в браузере, HTML определяет, что будет показано, CSS — как это будет выглядеть, а JS — всякие особые взаимодействия.

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON.

Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения

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

Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения

Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.

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

Вне фронтенда и бэкенда

Автономный фронтенд

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

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

Легкий бэкенд

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

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

Размытые границы

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

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

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

Источник: Tproger

Как разделить фронтенд и бэкенд, сохранив взаимопонимание

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

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

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

Предыстория

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

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

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

Фронтенд и бэкенд

Стать профессионалом во всём — долго и дорого, поэтому современный мир прикладных программистов делится, в основной своей массе, на фронтенд и бэкенд.

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

Для какого-то абстрактного нового проекта этого будет достаточно, но у нас уже было написанное приложение, а объёмы планируемых работ и сроки их реализации явно указывали, что одной командой обойтись не получится. В баскетбольной команде пять человек, в футбольной — 11, а у нас было около 30. Под идеальную скрам-команду из пяти — девяти человек это никак не подходило. Надо было разделиться, но как при этом сохранить связность? Чтобы сдвинуться с места, нужно было решить архитектурную и организационную проблемы.

«Всё сделаем в одном проекте, так будет удобнее» — говорили они…

Архитектура

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

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

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

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

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

Повысили устойчивость, разделив зоны ответственности.

Коммуникации

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

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

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

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

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

API

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

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

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

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

Другим распространённым решением является GraphQL. Он тоже не идеален, но в отличие от REST, GraphQL API — это не просто описательная модель, а настоящие правила.

Выше я говорил про систему, которая должна была согласовывать работу фронтенда и бэкенда. Прослойка (interlayer) — это именно тот промежуточный уровень. Рассмотрев возможные варианты работы с сервером, мы остановились на GraphQL в качестве API для фронтенда. Но, так как бэкенд написан на C++, то реализация GraphQL-сервера оказалась нетривиальной задачей. Не буду здесь описывать все возникшие сложности и ухищрения, на которые мы шли, чтобы их преодолеть, реального результата это не принесло. Посмотрели на проблему с другой стороны и решили, что простота — залог успеха. Поэтому остановились на проверенных решениях: отдельный Node.js сервер с Express.js и Apollo Server.

Далее нужно было решить, как обращаться к API бэкенда. Сначала смотрели в сторону поднятия REST API, потом пробовали использовать аддоны на C++ для Node.js. В итоге поняли, что это всё нам не подходит, и после подробного анализа для бэкенда выбрали API на базе gRPC-сервисов.

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

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

Общая схема работы после изменения архитектуры

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

Результат

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

1. За отображение отвечает фронтенд, а за данные — бэкенд.
2. На фронтенде сохранилась гибкость в плане запросов и получения данных. Интерфейс знает, что можно попросить у сервера и какие ответы должны быть.
3. На бэкенде появилась возможность менять код с уверенностью, что интерфейс у пользователя продолжит работать. Стал возможным переход на микросервисную архитектуру без необходимости переделывать весь фронтенд.
4. Появилась возможность использования mock-данных для фронтенда, когда ещё не готов бэкенд.
5. Создание схем совместной работы исключило проблемы взаимодействия, когда команды понимали одну и ту же задачу по-разному. Сократилось количество итераций по переделке форматов данных: действуем по принципу «семь раз отмерь, один раз отрежь».
6. Появилась возможность планировать работы на спринт параллельно.
7. Для реализации отдельных микросервисов теперь можно набирать разработчиков, не знакомых с C++.

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

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

Здесь я поверхностно затронул вопросы командной и межкомандной работы над одним продуктом, выбор технологи API (REST vs GraphQL), связь Node.js приложения с C++ и т. д. Каждая из этих тем тянет на отдельную статью, и если вам будет интересно, то мы их обязательно напишем.

“Front-end” и “back-end” Разработка

Разработка сайтов по системе front-end и back-end подразумевает иерархическое разделение процесса создания ресурса на две части, на разработку пользовательского интерфеса –(фронтэнда) и его программно-административной части (бэкэнда).

Front-end разработка – это работа по созданию публичной части сайта, с которой непосредственно контактирует пользователь и функционала который обычно обыгрывается на клиентской стороне (в

браузере).

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

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

При создании пользовательской стороны сайта и формировании html страницы мы учитываем следующие моменты:

• Грамотное использование тегов h2, h3 и т.д. в порядке очерёдности.
• Грамотное использование тега lang.
• Реальное заполнение атрибута alt для картинок. Если на картинке изображен логотип, то “Логотип компании”, если человек, то имя человеке. Для значков на английском языке “Twitter Icon” и т.д. (не относиться к динамическим изображениям, например, фото новости).
• Не забываем про метатеги.
• Не забываем про фавиконку (favicon).
• Там где предполагается ссылка, должна быть прописана ссылка.
• Для контактов использовать атрибуты skype, tel и mailto.
• Ссылки на внешние страницы должны открываться в новом окне.
• Каждая ссылка имеет атрибут title.
• Код хорошо прокомментирован.
• Оптимизация изображений для Интернета.
• Использование мобильных версий картинок, там где это необходимо.
• HTML, CSS и JS файлы должны иметь параллельно с основной (рабочей) и сжатую версию для последующего запуска сайта на хостинге.
• Все стили и скрипты вынесенны в отдельные файлы.
• Размеры всех картинок заданы средствами CSS.
• Использовать слайдеры, карусели и галереи адаптированны для мобильных устройств.
• Всплывающие окна адаптированны для мобильных устройств.
• Переименование файлов в случае использования кеширования.
• Подсветка (hover, active, visited) для ссылок.
• Подсветка (hover, active) для кнопок и полей в формах.
• Прижатый подвал при малом кол-ве контента на странице.
• Отсутствие outline у кнопок.

Back-end разработка

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

Бэкэнд производит обработку пользовательской информации полученной из front-офиса, и возвращает front-end’у результат в понятной ему форме.

Бэкэнд программирование — это веб программирование, целью которого является реализация серверной стороны сайта, интеграция базы данных и связь ее с пользовательской (front-end) стороной. Разработка бэкэнда сайта так же включает настройку и установку на сервер необходимого программного обеспечения.

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

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

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

Фронт? Бэк?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше

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