Начинаем цикл рассказов-интервью о том, чего ожидают от начинающих разработчиков в реальных проектах в разных ИТ-сферах: фронте, бэке, тестировании и всём остальном. Сегодня разговариваем про фронтенд с Алексеем Мартыновым, разработчиком и предпринимателем с более чем 20 годами опыта в ИТ. А ещё Алексей — программный директор на Веб-факультете Практикума и технический директор в проекте Akil.io. Он часто работает с новичками и знает всё о том, с какими проблемами и задачами они чаще всего сталкиваются на старте.
Эта статья — для тех, кто уже немного в теме: знает, что такое фронт, из чего он примерно состоит, понимает различия между HTML и JavaScript и пробовал сам собирать несложные веб-проекты, как в Коде. Если вы совсем новичок, но вам уже интересно, что будет ждать дальше в профессии, — тоже полезно, но может оказаться немного сложно. Чтобы как-то это упростить, будем давать много ссылок на наши статьи, где можно почитать про разные подходы и технологии более подробно.
Про вёрстку в целом
Главное и основное — хорошо понимать процесс рендера, то есть отрисовки страницы браузером, и то, как строится семантика сайта. От этого зависит качество кода, который получится.
Вёрстка на флексах и гридах
Сейчас использование в вёрстке flex и grid — основной подход к созданию страниц. Раньше, до них, мы часто использовали плавающие блоки (да и сейчас такое бывает), но с появлением флекса и грида вёрстка стала гораздо удобнее.
В чём здесь разница: флекс, условно, позволяет нам выравнивать блоки по одной оси, а грид — по двум осям, и мы выбираем, какой подход нам в тот или иной момент нужен.
Допустим, у нас страница из блоков, тогда это вертикальное выравнивание. Там где-то появляется список элементов и они будут переноситься при изменении масштаба, поэтому используем горизонтальный flex. А если нам надо создать какую-то жёсткую конструкцию и чётко расположить элементы относительно друг друга, то уже используем grid.
Вот эти тонкости и надо понимать на старте, что и для каких ситуаций лучше использовать. Дальше уже можно углубиться в рендер слоёв, в каком порядке используются правила и как вообще рендерится страница, но это следующий этап.
Понимание задачи
Есть две категории начинающих фронтенд-разработчиков, которые пришли на свою первую работу: те, кто просто делает, что им скажут, и те, кто старается понять, какие задачи стоят перед фронтом, и будет строить работу исходя из этого. Вторые ценятся в компании намного выше.
Например, такие ребята стараются разобраться в нюансах и понять, а для чего этот фронт вообще делается. И в зависимости от этого уже прикидывают, как сделать это лучше. Например, если мы делаем SEO-оптимизированный сайт, там одна специфика вёрстки. Если делаем адаптивный сайт — то какой: просто под разные размеры экрана или учитываем ещё слабовидящих? А нужно ли тогда добавлять поддержку скринридеров? А как это тогда лучше реализовать, чтобы сделать это сквозной историей на всех страницах?
И таких деталей много. Чем больше начинающий разработчик про это думает, тем быстрее он растёт как профи.
Про CSS
Кроме самого базового CSS и его правил на уровне стандарта CSS3, важно знать про препроцессоры и уметь работать хотя бы с одним. Самое популярное сейчас (хотя тут всё зависит от стандартов компании) — это Sass. Если хорошо его освоить, он экономит много времени несмотря на свою простоту. У него есть много возможностей, но самые базовые — это статические переменные, миксины и вложенность. На этом и стоит сделать упор при изучении Sass. Конечно, сейчас вложенность появилась у CSS, но до возможностей, которые дают препроцессоры, ей ещё далеко.
Почему важны препроцессоры
Представим, что у нас есть CSS-файл, в котором мы описываем какую-нибудь табличку, секции, блоки и так далее. Для единого оформления всего этого на странице нам приходится добавлять много повторяющихся правил, что сильно раздувает код и добавляет сложностей, если нужно что-то изменить. А в препроцессоре можно просто сделать миксин, который сделает одинаковое поведение и отступы для кнопок, контейнеров, секций и так далее. Дальше его можно переиспользовать на других страницах — и это здорово сжимает код и ускоряет вёрстку.
Анимации — это база
Без анимаций сейчас никуда. Они много где используются на сайтах и улучшают пользовательский опыт. Конечно, есть простые интерфейсы, но чем дальше развивается вёрстка, тем активнее используются анимации.
Базовые умения здесь — работа с фреймами и связанными элементами. Самый простой пример из задач для джунов — сделать лоадеры ожидания, крутилку или простой прогресс-бар. Или, сюда же, какие-нибудь переключения, когда блок из одного состояния переходит в другое. Например, когда на сайте появляется модальное окно, чтобы оно не просто появлялось внезапно на экране, а как-то аккуратно всплывало и расширялось.
Интерактив не должен быть избыточным, иначе он будет мешать. Но в нормальном количестве хорошая и продуманная анимация помогает пользователю взаимодействовать со страницей. Статистика показывает, что в этом случае пользовательский опыт лучше.
Про JavaScript
Помимо того, что на старте нужно знать циклы, переменные, условия, функции, их вызовы и так далее, важно как можно раньше разобраться в асинхронности и областях видимости.
Как работает асинхронность
Без асинхронного программирования у нас есть код, который выполняется линейно сверху вниз. Если есть какое-то ожидание, мы просто ждём, пока код сработает, прежде чем двигаться дальше. Формально JavaScript считается однопоточным, то есть всё исполняется в основном потоке, где происходит в том числе взаимодействие с интерфейсом.
Представим, что мы выбираем элемент, меняем его свойства и выводим что-то в консоль, и всё это выполняется строго по порядку, то есть синхронно. При этом происходит запрос на сервер, который занимает, например, 2 секунды. Из-за синхронности выполнения операций получится так, что интерфейс замрёт на время, пока запрос не завершится. И всё это время мы не сможем взаимодействовать с сайтом.
Чтобы избежать такого замораживания интерфейса, используют асинхронность, которая делает код нелинейным. Для этого создаются другие потоки, в которых обрабатываются асинхронные задачи, например запросы на сервер. Эти дополнительные потоки не блокируют основной поток. А когда операция завершена, она возвращает управление из дополнительного потока в основной.
Получается, что у нас есть куски кода, которые срабатывают и где-то висят в фоне — либо что-то делают, либо ждут ответа, — и это не мешает основной программе работать. Как только происходит что-то, на что у нас настроена асинхронность, этот кусочек кода такой: «Ребята, у меня вот есть новости, держите, пожалуйста», и остальной код такой: «Всё прекрасно, давайте обработаем». И в это время программа всё равно продолжает выполняться.
Как работают области видимости
Самая частая практика у начинающих — описывать вообще все переменные в самом начале до основного кода, так что к ним можно получить доступ из любой точки программы. Но в больших полноценных проектах это приводит к тому, что часть переменных занимает память 95% времени, а используется только в 5% ситуаций. Чтобы так не происходило, разработчики не делают все переменные глобальными, то есть доступными для всех, а зашивают их внутрь функции или, например, создают на время выполнения цикла.
Самое главное тут — не забывать о том, что переменная объявлена только внутри функции, и не пытаться к ней обратиться из другой функции или из основного кода. Если так сделать, JavaScript не будет ничего знать про эту переменную, остановит выполнение программы или вообще сделает что-то непредсказуемое.
Про паттерны программирования
Код — это решение каких-то задач, и для многих задач уже есть плюс-минус готовые проверенные решения. Они появились потому, что разработчики независимо друг от друга приходили к одинаковым решениям для схожих проблем. Эти обобщённые решения стали паттернами разработки, и их знание позволяет быстрее находить подходящие способы для решения задач.
Если разработчик не разбирается в паттернах, это будет видно по его коду: он будет непонятным. Даже в средних и крупных компаниях бывает, что разработчики изначально не задумывались о нормальной архитектуре и не заложили правила написания кода. А потом, как это обычно случается, резко происходит рост, разрастается кодовая база — и всё, приплыли. Чтобы всё работало и дальше, требуется жёсткий рефакторинг, полная переделка и так далее.
Чтобы не изобретать велосипед, нужно изучать не как писать строчки кода, а как из этого кода собрать решение. При использовании паттернов вы просто собираете код из каких-то готовых кирпичей. И у разных разработчиков код будет выглядеть плюс-минус похожим, потому что в нём будут стандартизированные решения.
Про стили программирования
Паттерны построены на объектно-ориентированном программировании. Это один из двух основных стилей программирования: помимо ООП есть ещё функциональный.
Чтобы разобраться, начнём с функционального. Это не разбиение кода на функции — это именно использование только чистых функций и отказ от глобальных переменных. Такой код хорошо тестируется, легко отлаживается и подходит для простых задач, в том числе реактивной разработки, например работы с потоками данных в интерфейсе.
У ООП основная идея другая: код структурируется в виде объектов, которые объединяют данные и методы, работающие с этими данными. Такой код получается модульным и легче масштабируется. Именно так будет удобнее работать, если у вас большие объёмы данных, например в сложных проектах, где нужно структурировать очень много связанных сущностей.
Нет такого, что какой-то из этих двух стилей правильный, а другой — нет. Всё зависит от задачи. И для разработчика важны гибкость и умение выбрать подходящий стиль. Поэтому изучать стили и паттерны программирования нужно ещё будучи новичком (и именно так обучают в Практикуме, если что).
Фронтенд — это не только про сайты
Создание интерфейсов для сайтов ничем не отличается от создания интерфейсов для умных телевизоров, автомобилей, холодильников и чего угодно ещё. Отличие — в ограничениях.
Для сайтов и мобильных приложений нужно предусмотреть, чтобы на разных экранах всё отображалось одинаково. Тут всё относительно просто: нужно использовать адаптивный дизайн и тестировать его на разных платформах.
Со встроенными устройствами сложнее: у одних устаревшие стандарты, в других не поддерживаются какие-то функции и так далее. Приходится подстраиваться под возможности конкретного устройства и учитывать его аппаратные ограничения: производительность, доступный экран и поддержку технологий.
Общий подход при этом остаётся одинаковым. Используются одни и те же HTML, CSS и JavaScript, а принципы создания интерфейсов остаются неизменными: удобство использования, визуальная структура и взаимодействие с пользователем.
HTML, CSS, JavaScript — а что ещё?
В дополнение к этим трём китам фронтенд-разработки хорошо бы знать TypeScript — он добавляет строгую типизацию и делает код более стабильным, а это уменьшает потенциальное количество ошибок.
А ещё реактивные фреймворки
Реактивные фреймворки — это инструменты для создания интерактивных веб-приложений, которые быстро реагируют на действия пользователей и изменения данных. Самые простые примеры таких фреймворков — React, Vue и Angular. С их помощью можно обновлять интерфейс, не прописывая вручную логику обновления, и работать с состоянием приложения, например контролировать, что должно отображаться и какая должна быть реакция на разные события.
Возьмём любое современное приложение. Оно будет состоять из интерфейса и его данных, серверных данных и действий пользователя. Интерфейс — это кнопки, поля ввода, списки и так далее, а его данные — то, что нужно показать в интерфейсе. Серверные данные — информация, которую приложение получает из внешних источников. Действия пользователя — это клики, ввод текста, перемещение ползунков и так далее.
Получается, что приложение должно обрабатывать действия пользователя, обновлять интерфейс в реальном времени, отправлять запросы на сервер и получать новые данные. Это достаточно однотипные события, и реактивные фреймворки помогают их автоматизировать. Например, если у нас есть переменная, которая отображается на экране, и значение этой переменной изменилось, то её отображение в интерфейсе обновит фреймворк.
Работает это так: мы декларативно определяем какой-то код, то есть описываем, как должно выглядеть приложение, а не как обновлять его интерфейс шаг за шагом. Например, с JSX в React мы пишем, что должно быть видно в интерфейсе, а React сам решает, как это реализовать. Если пользователь вводит что-то в поле, значение автоматически передаётся в состояние приложения, и если оно меняется, интерфейс обновляется.
Реактивные фреймворки идеальны для одностраничных приложений, они же SPA (Single Page Application). Это приложения, в которых страница загружается один раз, а все изменения происходят без перезагрузки. Браузер только получает данные с сервера, а интерфейс рендерится локально. К примеру, так устроен Telegram: сообщения, реакции и другие элементы интерфейса обновляются динамически, без постоянных запросов на сервер.
Диплом не нужен
Нет статистики, согласно которой наличие диплома о высшем ИТ-образовании сильно помогает (или мешает). Даже если вакансия требует, чтобы у соискателя был диплом, например если это госкомпания, этот диплом не обязательно должен быть техническим. В ИТ вам в первую очередь платят за то, что вы знаете и как решаете задачи бизнеса, а не за то, какой у вас диплом.
