Что это?ПодготовкаТестовые заданияСобеседование
Представьте, что вы зашли в ТГ. Все эти кнопки, меню, переписки, поля для ввода — всё, с чем вы взаимодействуете, это и есть фронтенд. Такая штука в вашем телефоне называется приложением. На компьютере — это веб-приложение. Задача фронтенд-разработчика — создать его интерфейс.

Фронтендер не просто «рисует» кнопки, а программируем их логику. Чтобы сообщение не просто появлялось в поле, а отправлялось и мгновенно доставлялось собеседнику. Обычно в проекте есть два основных «лагеря»: фронтенд (то, что видит пользователь) и бэкенд (то, что работает на сервере). Фронтенд-разработчик, неважно, пишет ли он под веб, телефон или даже для умного холодильника, делает так, чтобы у вас был удобный способ «общаться» с бэкендом. Ведь вы же не отправляете HTTP-запросы вручную, чтобы загрузить фото? Всё делается через интерфейс.

А теперь — как это выглядит изнутри, на проекте. Есть такая штука — Jira. Это такая продвинутая система для задач. Представьте себе доску со столбцами: «В плане», «В работе», «На проверке», «Готово». Задача — это карточка. Ты берёшь её из «В плане», перетаскиваешь в «В работе», а по завершении — в «На проверке».

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

Допустим, мне нужно «Сделать страницу просмотра заказа». В задаче обычно есть две ключевые ссылки: на дизайн в Figma (где всё показано с точностью до пикселя) и на техническое задание в Confluence (где расписана логика). Сначала я внимательно изучаю дизайн: как страница выглядит при разных состояниях (заказ оформлен, отменен, доставляется). Если что-то непонятно, иду в документацию. Если и там нет ответа — пишу аналитику или тимлиду. Я проверяю, готовы ли на сервере все нужные для страницы данные. Бывает, что бэкенд ещё не доделал свой кусок. Тогда я ставлю его в известность и временно переключаюсь на другую задачу. Когда всё готово, открываю редактор кода и терминал. Первым делом обновляю основную ветку develop (команда git pull), чтобы работать с самой свежей версией проекта. Затем создаю новую ветку для своей фичи (git checkout -b feat/order-view-page). Написал код — сохраняю изменения (коммит) с понятным сообщением, например, «feat: add order view page».

Проверка кода (Code Review). Я загружаю код в общий репозиторий (у нас GitLab) и создаю Merge Request (MR) — запрос на добавление моего кода в develop. В Jira я перемещаю задачу в «В ревью». Коллеги смотрят мой код, оставляют комментарии. Мы обсуждаем, я вношу правки. После одобрения (апрува) код вливается в основную ветку. Потом наступает очередь тестировщиков. Они ищут баги. Если находят — создают новую задачу, и я её исправляю. Готовый код по цепочке выкатывается на тестовые серверы через пайплайн — автоматизированный процесс сборки и развертывания. Если пайплайн «падает», мы ищем причину и чиним.

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

Шаг 1. Выбираем зык по вкусу (например, GO, JS или C#) и тщательно изучиаем его. Однако помните, что язык не главное, и вам нужно сосредоточиться на развитии широкого понимания технологий, используемых в вебе. Но парочку мыслей и рекомендаций к языку накидывали тут .

Шаг 2. Заходим сайт MDN и изучаем, как работает Интернет. На сайте представлен список других полезных ресурсов. Развитие широкого кругозора в вебе поможет вам в долгосрочной перспективе.

Шаг 3. Git — это система контроля версий, используемая при разработке программного обеспечения. Чтобы изучить его, могу посоветовать ресурс , бесплатный, удобный, прикольный. Вам не нужно быть экспертом в Git; вы узнаете его лучше, когда будете работать над своими проектами. Кстати, самое время ими заняться, самые популярные с рекомендациями оставлю тут .

Шаг 4. Linux — популярная операционная система которой пользуются многие разрабы. Можно глянуть например вот сюда .

Шаг 5. Кто бы что ни говорил, базовые алгосы — это важно, можно не уметь переворачивать красно-черные деревья, но знать чем массив отличается от списка и зачем нужна хэш таблица — обязан каждый. Эконом вариант: начать с «Грокаем алгоритмы», потом leetcode + лекции Паши Маврина. Но более эффективный вариант присмотреться к нашему курсу по алгоритмам курсу по алгоритмам , на котором семинары стартуют уже в эти выходные и

Шаг 6. Предположим что мы уже изучили основы объектно-ориентированного программирования (ООП) при изучении языка. Теперь пришло время изучить паттерны проектирования для создания приложений. Гляньте на SOLID, KISS и YAGNI. Зайдите на метанит , там куча информации.

Шаг 7. Теперь, когда вы знаете, как писать код и приложения, пришло время узнать о тестировании и методах тестирования. Эти знания помогут вам когда будете писать уже какой-то реальный код. Для начала подойдет любой тупой курс на том же степике.

Шаг 8. Изучите основы баз данных Postgres и Mongo. Вам не нужно углубляться, погрузитесь когда устроитесь на работу. 😍 REST API, JWT, клиент-сервер, GRPC, GraphQL, монолиты и микросервисы. К настоящему времени вы должны быть сильным джуном. Сосредоточьтесь на изучении REST API, JWT, клиент-сервер, GRPC, GraphQL, монолитах и микросервисах (важно понять разницу), советую еще вот это почитать.

Шаг 9. Изучаем кэширование и Redis .

Шаг 10. Изучаем Kafka и обмене сообщениями .

Шаг 11. Узнайте о контейнеризации и развертывании с помощью таких инструментов, как Docker, Docker Compose, Docker Swarm, Kubernetes и GitLab CI/CD. Вам не нужно быть экспертом в этих инструментах, но важно понимать, как они работают и зачем они нужны. У всех этих штук достаточно крутые документации, поэтому просто идем туда и читаем.

Шаг 12. Узнайте о балансировке нагрузки и проксировании с использованием Nginx и Traefik. Опять же, вам не нужно становиться девопсом, вам нужно просто знать что это такое и с чем его едят. Думаю, что когда вы дошли до этого этапа вам не нужны ссылки, сами знайте, где что брать.

Шаг 13. Когда вы придете на любой мало-мальски большой проект, у вас там все это будет. Вам нужно погуглить и узнать зачем нужны все эти слова: Jaeger, ELK (Elasticsearch, Logstash, Kibana), Grafana и Prometheus.

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

По этой ссылке собраны тестовые и прочие полезные материалы по фронтенд разработке. Если у вас есть чем подобным поделиться пишите в тг @vice22821, в долгу не останемся!
По этой ссылке собраны собеседования и прочие полезные материалы по фронтенд разработке. Если у вас есть чем подобным поделиться пишите в тг @vice22821, в долгу не останемся!