Фронтенд — это не больно!
Пособие для разработчиков и сочувствующих
Кадр из Fight Club, directed by David Fincher. 1999; USA: Fox 2000 Pictures.Пособие для разработчиков и сочувствующих
Кадр из 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. Если хочется поддержать проект или поблагодарить авторов, напиши нам письмо, пошарь книгу в соцсетях или задонать на кофе. Нам будет