KISS your website или как написать уважаемый сайт на аутсорсе, глава первая

Добрый день. Меня зовут Тимофей, я фронт-тимлид в диджитал-продакшене ДАЛЕЕ. В данном цикле статей я поделюсь подходами и инструментами фронтенд-разработки на аутсорсе, которые помогут создать качественный продукт без кошмарного instant-legacy и значительно облегчат жизнь команде разработчиков и не только.

Типичные веб-приложения в аутсорс-командах разрабатываются, как правило, год-два. За это время не раз успевают смениться как разработчики, так и менеджеры с заказчиками. Однотипных проектов в агентстве сразу несколько, разработчикам приходится переключаться между ними. Про отсутствие юнит-тестов на аутсорс-фронте, думаю, упоминать не нужно. Унифицировать процесс разработки в таких условиях не просто полезно — это нужно делать обязательно.

Расскажу, почему не стоит излишне усложнять архитектуру фронтенда, и дам примеры удобных и эффективных инструментов разработки с точки зрения DX (developer experience. Это важно) и дальнейшей поддержки.

Исторически сложилось так, что к бэку люди относятся серьезнее, чем к фронту — мол, там же данные (!), и все такое важное, а на фронте у вас только картинки и кнопки разноцветные. Поэтому подходы в разработке бэкенда более-менее стандартизированы: используются шаблоны построения архитектуры и взаимодействия между элементами, для них даже названия есть — MVC, MVP, и т.п.

С фронтом все не так. Шаблонов и стандартов из коробки, которые пропагандировали бы крупные акулы вроде Laravel, нет. Люди начинают экспериментировать.

Эксперименты обычно заключаются в том, что разработчики тянут на фронт подходы из бэкенда или используют молодые архитектурные решения. Например, Feature-Sliced Design (FSD), в рамках которого элементы распределяются на слои, слайсы и сегменты. Рекомендации по этому распределению есть, но это именно рекомендации — каждый волен использовать подход по своему усмотрению, что зачастую и происходит.

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

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

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

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

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

Речь не только об одном FSD-подходе. Современные архитектурные решения для фронта, в которых нет жестких правил, в конце концов приведут к росту трудозатрат, а разработчикам будет сложнее.

Как-то я писал приложение с нуля и тоже решил поэкспериментировать с моделями архитектуры. Сначала пробовал FSD на Vue, затем поставил vue-class-components и углубился в хардкор на TypeScript с Vue 2. В результате понял, что эти попытки не отвечают цели. Моя задача как разработчика — создать качественный продукт, который будет легко поддерживать и дорабатывать, а Vue 2 к тому времени уже был deprecated.

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

Изобретать велосипед не нужно: если вы пишете проект на Vue.js или React, не стесняйтесь — используйте архитектуру, которую предполагают эти библиотеки из коробки. Все компоненты в одной папке, максимально плоская структура, никакой вложенности. Keep it simple, stupid (KISS). Таким образом вы создадите удобренную почву для теоретически возможного крупного развития проекта в будущем, когда он перейдет из стадии быстрой аутсорс-поделки в полноценный продукт. То есть основная идея такого подхода — сознательное соглашение на, возможно, отталкивающий «внешний» вид проекта (короче как папки выглядят в IDE; тайлвинда дальше, кстати, тоже касается), в угоду скорости и качества разработки. Папка components будет выглядеть примерно так:

Связанные компоненты сразу можно заметить по названию, базовые — по префиксу App, страницы — по суффиксу Page. Важно заметить необычный порядок слов в названиях, к примеру InputDefault, LayoutDefault — это нужно для создания групп компонентов в пределах одной директории, а очевидная идея про «положить инпуты в /inputs, страницы в /pages...» не имеет практического смысла, так как это — не архитектурный подход, как многие думают, а просто дополнительная вложенность.

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

Строить однотипные проекты с точки зрения архитектуры — отличное решение, но есть инструменты, которые еще больше упростят разработку. В качестве примера расскажу о TanStack Query и Tailwind.

TanStack Query — это бывший React Query. Раньше он работал только для React, но после ребрендинга стал официально доступен для Vue и других фреймворков. До этого для Vue был неофициальный адаптер vue-query, который неплохо справлялся с задачей.

Это единое хранилище серверного состояния, которое зачастую используется в связке с микро-хранилищами клиентского состояния, например Recoil, Zustand, Pinia. TanStack Query унифицирует подход к созданию рутинных вещей.

Подавляющее большинство приложений пишутся по шаблону REST API с точки зрения взаимодействия серверного и клиентского состояния. Намного реже некоторые заказчики-олигархи решают затянуть в проекты GraphQL или RPC.

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

Пример для понимания (я пойду all-in, допустим, против Redux). Нам нужно получить постраничный список пользователей. Даже проще — нам нужно получить плоский список избитых todo-items. При этом сделать это по всем канонам: и чтобы код был хороший, и чтобы оверхеда много не было.

Мне нужны todo-items, черт возьми. При чем тут «диспачи» и «редюсеры»? Я не хочу заниматься хранением серверных данных — я хочу их получить и использовать. Не заниматься самоутверждением за счет «идеального контроля над данными», «четкого и предсказуемого потока» и прочих «аргументов» за использование Redux. В продукте — пожалуйста, на аутсорсе — ни за что.

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

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

Я хочу todo-items. Я говорю «дай мне todo-items». Я получаю todo-items. Как они кэшируются, обновляются, переиспользуются — меня не волнует. Захочу обновить — скажу «обнови» (вызову refetch), захочу избавиться — скажу «пометь как старье и удали, когда посчитаешь нужным» (вызову remove).

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

Сейчас TanStack Query не единственный в своем роде инструмент, альтернативы есть, например RTK Query, который позволяет Redux как-то жить на аутсорсе.

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

Раньше я, как и все фронтендеры, активно использовал частичный БЭМ: разделение сущностей в верстке на блок, элемент и модификатор.

БЭМ возможно и хорош, если его использовать правильно. Сразу пример: мне нужно добавить position: relative или display: flex на новый div — для этого по правилам я должен пойти в стили, придумать (да, иногда это тяжело) новое название, проследить чтобы это название, не дай бог, не конфликтовало с другими в проекте и написать одно CSS-свойство. Еще нужно всегда держать в голове принятый в данном проекте (какой же это тогда стандарт, черт возьми) стиль написания БЭМ-классов. Двойной ли дефис (--) или нижнее подчеркивание (_) — пойди разберись.

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

Дальше разработчики начинают стрельбу по коленям и создают себе «помощников»: классы flex, relative, margin-auto, hidden; активно их используют, и, глядите — внезапно БЭМ уже не БЭМ, а смесь непонятно чего:

В следующем проекте им надоедает создавать этих помощников вручную и они докидывают Tailwind, думая, что это набор так им нужных «хелперов» и получается такое:

Дизайн-переменные зачастую будут объявлены как в tailwind-конфиге, так и в css-файлах, какие же использовать при перекраске кнопки из синей в красную; какие из них актуальные? Правильно — никакие. Когда источников «правды», которой в данном случае является дизайн-система, несколько, у большинства разработчиков отношение к такому проекту стремительно катится на дно. «Да ладно, хуже уже не будет», — и вместо использования хотя бы какой-то переменной происходит вставка кода прямо из Figma для быстрого закрытия задачи.

Тут наступает пересменка, приходит другой человек, времени на то, чтобы разобраться, нет. В результате мы получаем ужас, три разных структуры в верстке: БЭМ, Tailwind и ручной код. Поможет только рефакторинг, но времени и ресурсов на него, конечно же, нет.

Выход из положения —использовать Tailwind для стилизации абсолютно всех элементов:

В последней на текущий момент версии появилась возможность использовать JIT-компиляцию для создания классов по типу h-[49px], mb-[12px], что позволяет использовать Tailwind повсеместно. Исключение будут составлять сложные тени, анимации и те вещи, которые в наборе Tailwind отсутствуют, что встречается довольно редко.

Разобраться в таком коде, на удивление, гораздо проще, чем в БЭМ. Все перед глазами, как и в случае с директорией components выше; стили внезапно (!) не протекают в другие места, не нужно придумывать названия и тащить вспомогательные средства.

Сильно углубляться в преимущества использования Tailwind не стану — у автора библиотеки есть потрясающая статья на этот счет, написал он ее еще когда подобные utility-фреймворки использовали только два с половиной фрика на pet-проектах. Настоятельно рекомендую ознакомиться, там подробно описано все вышесказанное с огромным количеством примеров.

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

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

В этой части я остановился на базовых вещах при разработке веб-приложений: как создать папки, как работать с данными и как эти данные красиво вывести. А в следующих материалах расскажу про поспешное затягивание в проект трендовых, сырых и экспериментальных решений, навязчивую необходимость использования TypeScript и правильную настройку линтеров для стандартизации кодовой базы.