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

Выходим за пределы серверной части

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

Мир серверной MVC, генерирующей HTML + JavaScript. Код JS разбросан по страницам. JavaScript в основном используется для улучшения UX за счет сокращения циклов просмотра сервера (Server View Cycles). Такие вещи, как отправка формы, проверка ввода и т.д. обрабатываются клиентским кодом.

Это самая распространенная архитектура в истории веб-приложений. Большинство приложений B2C, SEO-дружественных веб-сайтов, особенно созданных с помощью CMS — Content Management Systems, используют его. Количество клиентского кода зависит от потребностей приложения.

Эта архитектура как таковая никогда не была действительно стандартизирована и поэтому не имеет названия. Она развивалась инкрементном стиле и до сих пор считается расширением Web MVC. ASP.NET MVC, Java Struts, Python Django, Ruby ROR, PHP CodeIgniter — некоторые из широко используемых сред, широко использующих серверную MVC или Web MVC.

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

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

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

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

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

ShiftBrain Studio

Для начала прочитайте статью от Adham Dannaway Мой (простой) процесс дизайна и разработки сайта-портфолио (англ.).

Если первый вариант вашего портфолио не идеален — это нормально! Портфолио пройдет через множество итераций (рус.)

В первую очередь важно использовать при разработке все ваши навыки

Будьте в курсе

До тех пор, пока HTML и CSS не выйдут из употребления, важно оставаться в курсе всех событий в области фронтенда. Мир фронтенда все время изменяется

Мир фронтенда все время изменяется

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

Пользовательский опыт

▍Поддержка устаревших браузеров (полифиллы)

полифиллыэтомCan I Use

  • Angular. В документации к Angular есть особый раздел, посвящённый браузерной поддержке.
  • React. Проекты, создаваемые с помощью Create React App, поддерживают, как и ReactDOM, браузеры, начиная с IE 9. Эта поддержка основана на использовании полифиллов.
  • Vue. Здесь особенности поддержки устаревших браузеров описаны в к CLI.

▍Локализация и интернационализация

  • Использование на сайте выпадающего списка с перечнем языков, поддерживаемых проектом.
  • Доступ к сведениям о географическом местоположении пользователя (с помощью браузерного API Geolocation) и адаптация веб-сайта в соответствии с полученными данными.
  • Указание сведений о языке в URL. Например, это может выглядеть так: , или так: , или даже так: .
  • Angular. Angular, повторюсь, это полноценный фреймворк, он даёт разработчику готовое решение.
  • React. Задачи интернационализации проектов можно решать с помощью популярной в React-среде библиотеки react-i18next.
  • Vue. В решении рассматриваемых нами задач очень хорошо показывает себя библиотека vue-i18n.

▍Доступность контента

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

a11yproject.com

Angular. В документации к этому фреймворку есть особый раздел. Разработка доступных проектов поддерживается и на уровне Angular CDK.
React. Речь о доступности ведётся и в документации к библиотеке React. Существует и специальная библиотека — react-a11y

Но эта библиотека больше не поддерживается, поэтому пользуйтесь ей с осторожностью и учитывайте то, что её планируется заменить на библиотеку react-axe.
Vue. Разрабатывать доступные проекты на Vue поможет плагин vue-a11y

При создании библиотеки vuetify тоже учтены соображения доступности.

Паттерн BFF

  1. Клиентское приложение остаётся «глупым», и это предпочтительно с точки зрения безопасности и простоты использования. Чем глупее должны быть клиентские приложения, тем быстрее другие команды смогут создавать клиентские приложения. Кроме того, основная бизнес-логика и необходимая обработка данных остаются сокрытыми на стороне бэкенда.
  2. Увеличение задержки из-за дополнительного подключения в бэкенде теоретически должно быть меньше, чем влияние потребления дополнительных ресурсов во фронтенде.
  1. Из-за нового элемента (т.е. ещё одного сервиса) архитектура системы усложняется. В нашем примере рассматривается только один BFF, но потенциально вы можете создавать по одному BFF для каждого типа клиентских приложений.
  2. Из-за BFF-сервиса существует тесная косвенная связь между бэкендом и фронтендом. Да, смысл BFF на самом деле в том, чтобы контракт между бэком и фронтом был именно таким, какой нужен клиенту, что до минимума снижает вероятность внесения изменений в будущем. Однако эта вероятность никогда не равна нулю, и модификации в бэкенде или фронтенде подразумевают непосредственное изменение на другой стороне. То есть они связаны.

Двигаемся к Модели приложения (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.

Предыстория

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

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

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

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 станет больше.

Чистая архитектура. Искусство разработки программного обеспечения. Роберт Мартин

Да, последние книги про архитектуру, но иначе никак — разработчик не должен писать код ради кода, он должен думать о пригодности этого кода в будущем. Даже не так — разработчик должен писать код ради бизнеса. А чтобы он был ради бизнеса, он должен быть поддерживаемым в будущем. Роберт Мартин писал книгу не для Frontend-developer`ов, а для всех разработчиков и им сочувствующих

Мартин объяснил почему стоит уделять внимание архитектуре, как проводить архитектурный рефакторинг, с основными принципами, о которых также написано в refactoringGuru. (в refactoringGuru, как по мне, более подробно раскрыты некоторые моменты).Вопрос архитектуры приложений всегда для нас будет стоять ребром, потому что размер приложений с каждым днем увеличивается, а следовательно увеличивается их сложность

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

Заключение

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

Спасибо за внимание!

Базы кода

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

  • Lodash
  • Underscore
  • Babel
  • Ghost
  • NodeBB
  • KeystoneJS

Сворачиваемся

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

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

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

Это вторая часть в серии из двух статей. В этом руководстве не хватает введения в Node — платформу для работы JavaScript на стороне сервера. Возможно в будущем я напишу третью часть, в которой мы поговорим о разработке серверной части на Node и о вещах вроде баз данных noSQL.

Если вы хотите чтобы я подробно на чем-то остановился или у вас появились вопросы, то не стесняйтесь писать мне в Twitter.

Как стать frontend-разработчиком?

Чему учиться?

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

«В 2017 году я устроился на свою первую работу, зная лишь HTML, CSS, немного JavaScript и JQuery, — рассказывает Алексей Видякин. — Сегодня, в 2021 году, требования очень выросли, поскольку выросла конкуренция. Базовыми знаниями верстки уже никого не удивишь».

Вот примерный список требований к джуниор-специалисту в 2021 году:

Знать HTML и CSS. Под этим подразумеваются навыки кроссбраузерной и адаптивной верстки, знание популярных CSS-фреймворков, препроцессоров и HTML-шаблонизаторов.

Знать JavaScript, в частности стандарт Ecmascript 6 — спецификацию 2015 года, принесшую языку новые элементы синтаксиса и новый уровень производительности.

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

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

Уметь работать со сборщиком проектов (это небольшой код, определяющий последовательность действий при автоматическом запуске приложения из командной строки)

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

Базово знать один из современных фреймворков: React, Angular или Vue.js

С их помощью разработчик может минимизировать количество обращений к DOM (Document Object Model — объектная модель документа) и организовать мгновенный обмен данными с сервером через API. Вместо того чтобы по каждому клику перезагружать страницу целиком, фреймворк управляет состоянием ее отдельных компонентов, обеспечивая пользователю мгновенный отклик приложения. Подразумевается, что если человек сумел освоить один из них, то сможет достаточно быстро разобраться с другим, если возникнет необходимость. Есть довольно много вакансий, где требуется какой-то конкретный фреймворк.

Знать английский. Не факт, что от соискателя сразу потребуется обсуждать что-то со штаб-квартирой Facebook, но реакции «Тут нет документации на русском, поэтому я не смогу разобраться» тоже уже не принимаются.

Где начать работать?

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

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

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

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

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

Траектории того, как приходят во frontend, разные. Читайте историю Марка Соболева, который служил в полиции, а теперь разрабатывает образовательные сервисы.

И не забывайте развлекаться

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

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

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

P.S. от переводчика:

Machine learning in Frontend. Trial

ML может применяться в задачах разработки веб-интерфейсов. Благодаря библиотеке Tensorflow, которая является одной из популярных библиотек для ML и имеет версию для Node.js и браузера, мы получаем возможность машинного обучения на известном стеке. Здесь JavaScript подтверждает свою универсальность.

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

Одна из наших команд экспериментировала и сделала сервис, предсказывающий вероятность посещения следующей страницы. Затем интегрировала этот сервис в стратегию предзагрузки одного из проектов — теперь в некоторых случаях пользователь при переходе на следующую страницу увидит ее моментально, без ожидания загрузки. Мы разработали свое решение на базе Tensorflow.js. Конкретно для этой задачи существует open-source-решение от Google — Guess.js, которое на основе данных из Google Analytics делает похожее. Советуем попробовать.

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

Аналитика

▍Наблюдение за поведением пользователей и A/B-тестирование

  • Google Analytics (GA). Существуют руководства по использованию GA в Angular, React и Vue.
  • Kameleoon. Это — основанный на технологиях искусственного интеллекта фреймворк для персонализации и A/B-тестирования веб-проектов.

▍SEO

  • Angular. Вот интересная статья по поисковой оптимизации, которая применима к Angular- и к Angular Universal-проектам.
  • React. Вот материал об общих проблемах SEO в React-проектах. Вот — статья об улучшении поисковой оптимизации React-приложений.
  • Vue. Вот подробная статья о поисковой оптимизации Vue-приложений.

Интерактивность

Одна из областей применения JavaScript — добавление интерактивности вашей странице

Теперь, когда у вас есть представление о JavaScript как о языке, можно перейти к его применению в вебе. Для понимания того, как JavaScript взаимодействует с сайтами, вы должны сначала узнать об объектной модели документа (DOM).

DOM является отражением структуры HTML-документа. Это древовидная структура, состоящая из объектов JavaScript, которые соответствуют узлам HTML. Для дальнейшего изучения DOM, прочитайте Что такое DOM? в переводе Frontender Magazine. Статья даст вам простое и понятное объяснение понятия DOM.

Инспектируем DOM

JavaScript взаимодействует с DOM и изменяет или обновляет его. Вот пример, в котором мы выбираем HTML элемент и изменяем его содержимое:

var container = document.getElementById(“container”);container.innerHTML = 'New Content!';

Не волнуйтесь, что это какой-то очень элементарный пример. Вы можете сделать гораздо больше этого при помощи манипуляций с DOM. Чтобы узнать больше о использовании JavaScript для взаимодействий с DOM, пройдите в раздел Руководство по DOM в документации MDN.

  • Введение в DOM
  • Events
  • Examples of web and XML development using the DOM
  • How to create a DOM tree
  • Locating DOM elements using selectors

Опять же, сосредоточьтесь на понимании концепции, минуя синтаксис. У вас должны быть ответы на следующие вопросы:

  • Что такое DOM?
  • Как обратится к элементам?
  • Как добавить обработчик событий?
  • Как изменить свойства узла DOM?

Для получения полного списка доступных манипуляций с DOM при помощи JavaScript, обратитесь к JavaScript Functions and Helpers от PlainJS. Этот сайт содержит объяснения того, как, например, менять свойства стилей HTML-элементов или обрабатывать события клавиатуры. Если вы хотите копнуть глубже, то вы всегда можете прочитать раздел о DOM в книге Выразительный JavaScript.

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

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

Начните создавать реальные проекты

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

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

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

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

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

Затем уже можно будет создать небольшое резюме. Все проекты, которые вы завершили самостоятельно, особенно те, которые демонстрируют ваши навыки и способности, должны быть добавлены в ваше резюме. Также можно добавлять из на github, чтобы работодатели видели уже все примеры ваших навыков.

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

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

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

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

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

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

Dieter Rams Clock

Эксперимент 4 объединяет все что вы узнали о HTML и CSS, а так же знания по JavaScript. В рамках этого задания вы создадите часы с собственным дизайном и сделаете их интерактивными при помощи JavaScript. Перед началом я рекомендую прочитать Decoupling Your HTML, CSS, and JavaScript с целью изучения основных соглашений по именованию классов в случаях, когда в разработке участвует JavaScript. Я так же подготовил список примеров на CodePen. Вы можете использовать их как шпаргалки для этого эксперимента. Если нужно больше — поищите по слову clock на CodePen.

  • Flat Clock
  • Настенные часы на jQuery
  • Fancy Clock
  • Retro Clock
  • Простые часы на JavaScript

Есть два способа выполнения этого задания. Можете начать с проектирования и создания макета на HTML и CSS, а затем добавить JavaScript. Или вы можете сначала написать логику на JavaScript, а затем перейти к разметке и стилям. Вы можете использовать jQuery или чистый JavaScript.

JavaScript-фреймворки

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

Я не буду описывать все JavaScript-фреймворки. Тем не менее вот краткий перечень основных: Angular, React + Flux, Ember, Aurelia, Vue и Meteor. Вам не нужно изучать их все. Выберите один и научитесь работать с ним. Не пытайтесь угнаться за всеми новинками. Вместо этого постарайтесь понять основную философию разработки и принципы, на которых строятся фреймворки.

Секреты Javascript Ниндзя. Джон Резиг, Беэр Бибо, Иосип Марас

У каждой книги есть своя цель, и у этой книги она тоже есть. Цель — напомнить вам о том, что есть в чистом js, что есть в браузере, что такое DOM и какие есть возможности у него.Она буквально вам говорит: «Отвлекитесь от фреймворков и библиотек — посмотрите что умеет язык без этого!». На страницах есть краткая информация для повторения основных понятий в js, некоторых стандартных приемов работы, например, с событиями. Все это приправлено от души хорошими примерами кода.Книга хороша своим грамотным делением на главы и простым языком изложения. Тот самый случай, когда на ночь можно почитать не только с удовольствием, но и с пользой.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector