О чем плачет Frontend-developer

1. Первый рабочий день — обман ожиданий

Ты приходишь в новую компанию, всё кажется крутым: светлый офис (или уютный хоум‑офис), дружелюбная команда, проекты мечты. И тут начинается:

Настройка окружения

Ты клонируешь репозиторий, уверенный, что всё пойдёт гладко. Но через полчаса ты уже гуглишь ошибки с NPM и Node.js, сталкиваешься с конфигами Webpack, которые больше похожи на книгу по черной магии, и думаешь: «Как оно вообще работает?». Ты пишешь в чат команды:

• «Ребят, а кто‑нибудь сталкивался с этим багом при установке зависимостей?» И тут приходит ответ:

• «А у нас инструкция в Confluence есть, сейчас скину ссылку».

Ты открываешь её, а там… статья 2018 года с командами, которые уже не работают, но с комментарием: «Если что‑то не запускается, напишите Саше». Саша уже уволился, а ты остаёшься с этой головоломкой один на один.

Первый таск

Тебе дают задачу, чтобы ты «плавно вошёл в процесс». Та самая задачка на полчасика:

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

• Поправить баг в модуле, который не трогали уже три года. Ты находишь файл с кодом и видишь: const magicNumber = 42; // не трогать, иначе всё сломается. Вопрос «почему?» остаётся без ответа.

• Сверстать форму, но вот беда: макета нет. Дизайнер уехал в отпуск, и тебе говорят: «Придумай сам, как будет красиво». Нет, я не плачу… Просто «неочевидная валидация» в глаз попала.

Онбординг: как он есть

• С тобой проводят созвон, рассказывают о проекте и компании, но ты понимаешь половину слов, потому что всё звучит как: «Мы используем кастомные хуки для обработки data‑layer в Redux Middleware, но на проде это через proxy». Ты делаешь вид, что понял, а потом открываешь Google и пытаешься вникнуть.

• Тимлид подбадривает: «Не переживай, мы тут все с чего‑то начинали». А сам пишет код так, что кажется, будто он изобрёл новую ветку математики.

Итоги первого дня

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

2. Дизайнеры и их «чуть-чуть»

Работа с дизайнерами — это как пытаться понять язык инопланетян. Всё красиво и логично, пока ты не начинаешь в этом копаться. Тебе может повезти, а может и нет.

«Небольшие изменения»

Дизайнеры, как правило, начинают с фразы: «Тут просто немного поменяли, ничего серьёзного». Ты видишь новый макет и чувствуешь, что это «чуть‑чуть» — это как если бы тебе сказали: «Ты всего лишь перестроишь здание, но стены уже стоят».

• Ты открываешь файл и понимаешь, что переделывать нужно не одну кнопку, а абсолютно все экраны. Эта кнопка часть корпоративной UI библиотеки. Тебе надо меня StoryBook. А новое изменение в UI ломает отображение в 70% всех компонентов. Весь макет перевёрнут, новые шрифты, изменения в отступах, шторки, элементы интерфейса… Словом, всё. Это уже не «чуть‑чуть», а новый проект.

• Вместо стандартных 20 пикселей отступа теперь стало 15, а то и 25. И вот ты начинаешь искать, где этот отступ по всему коду, пытаясь не сломать остальные части интерфейса. А когда меняешь ломается весь контейнер.

Версия 2.0 макета

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

• Цвет кнопок: с голубого на красный.

• Тень у карточек: добавили, но не сказали.

• Логотип не просто увеличили, а поменяли векторную графику на совершенно другую.

И тут уже не помогает даже хорошо настроенный git. Ты начинаешь менять элементы и понимаешь, что половина кода больше не имеет смысла. Вроде не сложно, но объём работы сразу увеличивается в 2–3 раза. Ты сидишь и думаешь: «Вот это я попал!».

Иконки и пиксели

А самое весёлое — это иконки.

• Дизайнеры любят выслать «новую коллекцию иконок» в стиле «flat», а ты сидишь и верстаешь этот элемент, с каждым разом, меняя их местами, пытаясь соблюсти идеальные размеры. Размер иконок при этом разный с учетом пропорций добавляются внутренние отступы

• «А можно иконку сделать на 2 пикселя меньше?» — кажется, что ты сошёл с ума, потому что все размеры теперь не сходятся.

Как это выглядит с другой стороны

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

• «Как это не отобразилось на других устройствах? Ведь всё должно работать одинаково!» — говорит дизайнер, не понимая, что ты запиливал кучу кода под старые условия, и теперь всё надо переработать.

• «Но ведь это же несложно!» — говорит дизайнер, подразумевая, что изменить несколько пикселей на картинке или цвет на кнопке — это 2 минуты работы. А ты вот уже 3 часа тратишь на подгонку всех макетов под эти мелкие изменения.

3. Legacy-код — мой личный монстр

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

Когда всё ломается, а причины нет

Вся суть legacy‑кода в том, что он вроде бы работает, но никто точно не понимает, как именно. Ты начинаешь исследовать старый код и натыкаешься на такие комментарии, как:

• // TODO: разобраться, почему это работает.

• // Этот баг возник ещё в 2015, но до сих пор никто не починил, так что лучше не трогать.

• Или самый любимый: // Не меняй эту часть, если не хочешь поломать весь проект.

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

Кастомные решения, которые ломаются со временем

Legacy‑код часто бывает написан с учётом того, что в будущем на него никто не будет смотреть. Часто используемые «костыли» могут выглядеть как будто бы решение проблемы, но на деле это лишь быстрый выход, который никто не удосужился оформить должным образом.

• Ты можешь найти что‑то вроде:

  const data = someData || []; // на всякий случай, потому что иногда someData == undefined

  Это «костыль», который вроде бы решает проблему, но он работает в определённых условиях, а ты не знаешь этих условий. Пытаешься разобраться, а баг появляется в самом непредсказуемом месте.

Никто не помнит, почему так

Ещё одна классика — это когда ты изменяешь что‑то, и всё работает «как раньше», но через некоторое время появляются странные баги, о которых никто не мог бы подумать. Старые функции и компоненты могут работать только потому, что ты их не трогаешь, но как только ты начинаешь модернизировать код, появляется куча проблем.

• Ты заглядываешь в репозиторий и видишь сотни маленьких PR, в которых всё‑таки исправляли что‑то, но каждый раз только усложняли ситуацию.

• Ты сталкиваешься с тем, что документации нет, а старые разработчики уже не работают в команде. А те, кто остались, не помнят деталей, потому что писали код ещё 5 лет назад.

«Не трогай, оно работает»

Ты начинаешь всё переписывать, потому что видишь, как можно улучшить код, но здесь приходит главный момент — команда!

• Тимлид говорит: «Не меняй, оно работает!». И ты слышишь этот страшный голос из прошлого: «Мы не трогали это полгода, и всё нормально, так что и ты не трогай».

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

Тесты и баги

Обычно в legacy‑коде тестов нет или они написаны так, что от них только хуже.

• Ты пытаешься разобраться с багом, а оказывается, что система не тестируется никак. И всё, что ты можешь — это писать тесты самостоятельно, а это требует времени.

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

Клиенты и пользователи

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

4. Таски и дедлайны — вечно не успеваешь и всё срочно

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

Новая задача за час до дедлайна

Время близится к концу рабочего дня, ты почти завершил важную задачу, и вот он, последний штрих. Ты уже можешь на 100% уверенно сказать: «Задача сдана, можно выдохнуть». Но тут приходит уведомление:

• «Кстати, нужно ещё добавить анимацию на этот элемент».

• Или: «Ты можешь поменять текст в карточке? Поменялся заголовок на сайте».

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

Когда задачи не горят… но вдруг загораются

Ты приходишь в офис (или открываешь рабочее пространство на удалёнке), и тебе говорят, что «эти задачи не срочные». Вроде бы тебе дали пару дней, чтобы на расслабоне всё сделать. Но как только ты начинаешь работать, приходит новая, более срочная просьба.

Например:

• «Нам нужно срочно сделать интеграцию с новым API, потому что у клиента завтра демо».

• Или: «Проектный менеджер сказал, что к следующему месяцу должна быть новая фича на проде».

• «Твои текущие задачи теперь в завтрашнем релизе»

И тут начинается паника. Ты срочно перераспределяешь время и начинаешь молиться, чтобы не упустить что‑то важное. Вместо спокойного планирования возникает ощущение, что твоя работа теперь — это гонка с вечными горящими дедлайнами.

Нереалистичные сроки

Иногда разработка фичи по расписанию — это вообще отдельная трагедия. Например, тебе говорят: «Нужно за неделю сделать новую версию интерфейса». Ты спрашиваешь: «А у нас есть макет?». Ответ: «Есть, но дизайнер только закончил, поэтому будут мелкие правки».

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

• Макет еще не согласован, и ты не можешь начать верстать, пока нет окончательной версии.

• Фичу надо привязать к старой логике, которая запутана и требует рефакторинга.

• Нужно ещё настроить юнит‑тесты, чтобы не поломать старое приложение.

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

Многозадачность — угроза твоему здоровью

Многозадачность на фронтенде — это когда тебе нужно одновременно:

• Добавить новый компонент.

• Исправить баг в старом компоненте.

• Реализовать новую фичу с запросами на сервер.

• Написать тесты.

• Внести мелкие правки в дизайн, чтобы всё стало идеально.

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

Неудачные приоритеты

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

• «Мы понимаем, что вы тут делаете новую фичу, но на проде лежит баг, который по мнению клиента — критичный».

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

5. Команда — спасение и разочарование

• Когда ты потратил 3 дня на идеальный код, а сеньор в PR пишет: «Код хороший, но можно проще». Ты делал всё по максимуму, а оказывается, что можно было бы и проще — и вся твоя усердная работа просто сводится к минимуму.

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

• Когда команде нужно срочно что‑то сделать, и ты забрасываешь свои идеальные идеи, чтобы просто закончить задачу. Все ждут, что ты дашь решение, и ты не можешь тянуть, потому что проект не ждёт. И даже если решение не идеальное — главное, чтобы работало.

6. Кроссбраузерность — проклятие всех фронтендеров

Тебе кажется, что всё работает идеально, а потом кто‑то открывает сайт в старом IE или на Android, и тут начинается кошмар.

• Когда ты проверяешь код на последних версиях браузеров, всё отлично, сайт работает идеально, и ты гордишься собой. Но приходит тестировщик и говорит: «В Chrome работает, а в Firefox — нет». Ты перечитываешь свои стили и начинаешь кидаться матами.

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

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

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

8. Заключение: Почему мы всё ещё здесь?

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

Ты сидишь перед компьютером, иногда чувствуешь себя как тот персонаж в компьютерной игре, который пытается пройти уровень, но каждый раз попадает в ловушку. Но в какой‑то момент ты осознаёшь: это твоя игра. И если ты не будешь бороться с этим, то кто? В конце концов, ты нашёл свой путь — через все баги и бессонные ночи.

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

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