Фронтенд — это не больно!

Пособие для разработчиков и сочувствующих

Кадр из Fight Club, directed by David Fincher. 1999; USA: Fox 2000 Pictures.

О чём это и для кого 🔗

У фронтендеров постоянно бомбит.

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

Грустные фронтендеры пытаются бороться с этим, но сдаются и утопают в рутине.

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

Боль фронтендера 🔗

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

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

Фронтендеру жалко свой код
Фронтендеру жалко свой код
Но ведь я это делал 4 часа в субботу, когда меня в офисе вообще не должно было быть! И так задач немерено, а тут вы ещё со своими пикселями! Мне таски надо закрывать, у меня сроки горят!

Им кажется, что их идеи «мочат» и не дают расти. Будто команда сговорилась против них и не понимает, как надо работать. Но это, конечно же, полная дичь.

Фронтендерам платят не за код 🔗

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

Моя задача не в том, чтобы писать код? Но мне же за это платят
Когда узнал, что тебе платят не за код
Когда узнал, что тебе платят не за код

Не за это. Пофиг, сколько строк написано и сколько часов просижено за монитором. Важен результат — то, что код в итоге делает.

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

Задача фронтендера — понять, в чём польза проекта, над которым он работает

Приносить пользу — приятно. Ребята из опенсорса не дадут соврать. Видеть, что результатами работы пользуются люди — клёво.

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

Фронтендер, дизайнер, бекендер, тестировщик, менеджер, клиент — все равны и делают одно дело: продукт для пользователей.

Та‑а‑ак, падажжи. Все равны, делают продукт, бла‑бла. Я просто страницы верстаю. Мне дают макеты, я делаю…
Та-а-ак, падажжи
Та‑а‑ак, падажжи

И от твоей вёрстки зависит многое. Фронтендеры — это строители. Архитектор не скажет строителям: «Вот тут мы поставим высотку без фундамента». Они его нафиг пошлют, потому что знают, что высотка рухнет. У фронтендера в проекте та же роль, что у строителей.

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

Но меня ведь никто не слушает!..

Как видят проблему другие 🔗

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

Но фронтендер — специалист. Ты знаешь то, чего могут не знать другие
Используй силу
Используй силу

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

Перестать ныть. Когда ноешь, всем кажется, что ты просто отлыниваешь от работы. Будто тебе ничего не стоит переверстать с нуля пару страниц, но тебе просто лень.

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

Да как вникать‑то? Никто ж не объясняет. Начинаешь спрашивать, тебе сразу «иди верстай, не тормози»

У фронтендера есть право голоса 🔗

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

«Тут надо кое-что переверстать»
«Тут надо кое‑что переверстать»

Здесь сначала надо успокоиться и понять, что ни у кого нет задачи «замочить фронтендера». Дизайнеру, менеджеру и тестировщику незачем тебя ненавидеть. Но и дизайнер, и менеджер, и клиент переживают за проект и хотят сделать работу качественно.

Ни у кого нет задачи «замочить тебя»

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

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

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

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

Последнее слово не всегда за дизайнером

Другая частая проблема: у дизайнера в макете разные отступы. У одного заголовка 10 пикселей, у другого такого же — 8, у третьего — 11.

Что делает фронтендер? Накладывает полурозрачный макет поверх и выравнивает все отступы до пикселя. Потом приходит переделанный макет, и там все отступы отличаются на 1–2 пикселя от прежних.

Баг это или фича, непонятно. На всякий случай фронтендер снова накладывает макет и переделывает отступы по новой. А потом ещё раз. А потом ещё. А потом спрашивает, откуда столько рутины.

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

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

Как сделать, чтобы тебя услышали 🔗

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

Проблемы можно и нужно обсуждать с дизайнером и командой

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

Я бы и с радостью, но не выходит…

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

Собеседнику важно видеть пользу для себя от переговоров

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

В переговорах надо постоянно прокачиваться. Сначала не будет получаться, поэтому надо больше практиковаться.

В переговорах надо прокачиваться

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

Облегчай себе работу — копи знания 🔗

Чем больше знаний, тем проще работать.

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

Второй способ — задавать вопросы. Время на приобретение опыта уже не тратится, он уже в ответе на вопрос, его можно применять. Для фронтендеров самое то.

А ещё, задавая вопросы, ты начнёшь понимать, как люди принимают решения.

Но нафига мне это? Мне бы со своими задачами разобраться…

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

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

Знания помогают быстрее решать задачи и избегать лишней сложности

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

Большая часть доделок у фронтендеров возникает именно из‑за непонимания, какой требуется результат. Чем создавать себе лишнюю работу, лучше избавиться от неё заранее.

Вначале думай — потом делай
Вначале думай — потом делай

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

Да блин… Чё мне больше всех должно быть надо?

Да! Это же в твоих интересах сделать сразу нормально и не переделывать. Менеджеру пофиг на твоё личное время :–)

Сделать нормально и не переделывать — в твоих интересах
Сделаешь фигово — придётся переделывать
Сделаешь фигово — придётся переделывать

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

Пойми задачу и только после этого начинай её решать

Запоминай всё что говорят или объясняют, записывай, веди чеклисты. Если какое‑то решение непонятно (вот тебе сказали подвинуть лого на пиксель вниз), сделай, а потом спроси, почему именно так.

Не воспринимай критику как оскорбление. Прислушивайся к замечаниям, они помогут быстрее вырасти в новой области.

Не воспринимай критику как оскорбление

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

Развивайся 🔗

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

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

Фронтендер — тоже дизайнер 🔗

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

Фронтендер тоже дизайнер
Фронтендер тоже дизайнер

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

Типографика и вёрстка

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

Анимации

Научишься управлять вниманием пользователя и расставлять акценты на странице. Сможешь отличать уместные анимации от неуместных. Узнаешь, как создавать простые в реализации, но красивые анимации.

Интерфейс и представление информации

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

Тоже редактор 🔗

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

Тоже бекендер 🔗

Знание бекенда поможет понять, как устроен проект на сервере. Сможешь оптимизировать логику запросов, улучшить загрузку страниц, оптимизировать загрузку статики на фронт.

Тоже тестировщик 🔗

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

Тоже инженер 🔗

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

Тоже менеджер и маркетолог 🔗

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

Зная, как работает экономика и как люди принимают решения, будешь понимать, как пользователи относятся к проекту.

Эволюция продукта 🔗

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

Типичный дизайнер в проекте
Типичный дизайнер в проекте

Продукты развиваются: какие‑то части устаревают, какие‑то добавляются.

Переписывать код придётся постоянно, но это не должно мешать нормально работать

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

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

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

Научись работать с этими концепциями и инструментами так, чтобы строить свою работу независимо от остальных.

«Фронтендер обновляет зависимости»
«Фронтендер обновляет зависимости»

Ну например:

Бекендеры поменяли APIИспользуем паттерн адаптер
Дизайнер попросил вернуть фичу двулетней давностиВосстанавливаем фичу из гита
Менеджер дал на длинный лендинг всего два дняСобираем страницу из подготовленных заранее модулей и компонентов

Будь гибче. Не делай свою работу хрупкой — много переделывать потом не понравится самому.

Но ведь… макеты же! Там всё было по‑другому
«Но ведь… макеты же!»
«Но ведь… макеты же!»

Ну бывает :–)
Да, по‑другому, и ладно. Макеты — картинки, они быстро устаревают.

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

В смысле пофиг на макеты? От меня требуют пиксель‑пёрфект. При этом всё постоянно перерисовывают. И как я должен с этим справляться?

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

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

Внедрить дизайн‑систему трудно. Никому не хочется делать дополнительную работу. Сначала даже всем кажется, что она только замедляет процесс. Поэтому без переговоров тут — никуда :–)

В работе никогда не будет чётких этапов: «нарисовали», «заверстали», «прикрутили» — это нормально

Это не значит, что полный редизайн за неделю до релиза — это нормально. Если такое происходит часто, надо поговорить с дизайнером, чтобы как‑то поправить процесс.

Чем проще — тем лучше 🔗

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

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

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

Но не всегда чем больше фич, тем лучше. Чем продукт проще, тем проще его поддерживать и тем он понятнее для пользователей. Поэтому принцип KISS полезен не только для программистов, но и для продуктов.

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

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

Конвейер 🔗

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

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

Это плохо.

Задай себе вопрос: что тебя тут держит? И подумай, стоят ли печеньки того времени, которое ты убиваешь на это.

Что, просто взять и уйти? А если меня никуда больше не возьмут?

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

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

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

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

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

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

А если мне ничего не нравится? Я, может, вообще делаю это всё только ради денег

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

Что дальше? 🔗

Дальше — развиваться и делать классные вещи в вебе. Мы собрали все советы в чеклист. Распечатай его, пусть будет на виду.

Главное не останавливайся, потому что всегда есть, куда расти. И помни: работа не должна быть каторгой, фронтендер не должен быть грустным.

P.S. Баги, опечатки, идеи и предложения присылай в Телеграм или на Гитхаб.