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

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

Кадр из 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. Баги, опечатки, идеи и предложения присылай на почту или на Гитхаб.

P.P.S. Если хочется поддержать проект или поблагодарить авторов, напиши нам письмо, пошарь книгу в соцсетях или задонать на кофе. Нам будет приятно :–)