Всем привет! Меня зовут Егор, я – фронтенд-разработчик в Чиббис, один из трёх разработчиков новой версии важного продукта компании – партнерского личного кабинета.
Проект создавался с нуля, и перед командой стояла задача подойти к разработке нового продукта с максимальным, насколько это возможно, соблюдением всех «идеальных» процессов разработки: была возможность попробовать не только внедрить, но и применять на постоянной основе различные практики разработки. Те из вас, кто работал на давно уже существующих проектах, знают, как сложно и муторно переезжать на любой новый стек, не говоря уже о том, чтобы вводить в обиход новые практики: как правило, подобные вещи остаются на уровне экспериментов и не уходят дальше.
Сегодня я хотел бы поделиться с вами нашим процессом разработки, который сложился у нашей команды при работе на этом проекте. Зачем? Мне кажется, что информация о готовых процессах/воркфлоу/циклах/итерациях разработки на Feature-Sliced Design (далее – FSD) встречается значительно реже, чем какие-то базовые рекомендации, правила и сухая теория этого архитектурного паттерна.
В статье будет представлен готовый шаблонный процесс от А до Я, который позволит вашей команде пройти путь "from zero to hero" (от пустой папки проекта до готового бизнес-продукта с большой пользовательской аудиторией). Вам решать, насколько процесс получился оптимальный. С интересом выслушаю критику сообщества. В спорах рождается истина и возможно, что-то мы сможем взять в работу. Но сначала немного о команде и о самом проекте.
О проекте и мотивация выбора FSD
Чиббис - маркетплейс доставок еды в 190+ городах РФ, крупный игрок на рынке российского фудтеха, с 8000+ ресторанами-партнерами и 3+ млн клиентов. Наша киллер-фича – возможность заказывать бесплатное блюдо за накопленные баллы с каждым заказом (даже с первым).
Личный кабинет партнера – b2b-приложение для партнеров (ресторанов), позволяющее управлять своими заведениями на нашей платформе, а именно просматривать и работать с отзывами, формировать меню и карточки продуктов, управлять заказами и анализировать их историю и статистику, подключать новые филиалы и управлять временем их работы и так далее. Функционала в приложении чуть ли не больше, чем на основном сайте (https://chibbis.ru/).
Естественно, есть и старая версия приложения, но создавать новую с нуля казалось (и оказалось) правильным решением – абсолютно новый дизайн, новый подход к UX – все это требовало фундаментальной переработки кодовой базы. Скажу сразу, что проект создавался без какой-либо оглядки на предыдущий.
Итак, FSD. Будем честными, про FSD-архитектуру/методологию/подход сегодня не слышал только ленивый и про него точно нельзя сказать, что он обделен вниманием. Как я уже говорил, в этой статье я бы хотел поговорить не про основы FSD, т.к. материалов по данной теме хватает (вроде бесконечно обсуждаемого разбиения по слоям), а про сам процесс разработки на FSD.
Во время разработки у нашей команды накопился богатый багаж знаний и уйма материалов по основам FSD, что привело к созданию мной документации для разработчиков, покрывающей весь проект. Поэтому, если тема покажется интересной, пишите в комментарии, буду рад поделиться накопленной информацией в рамках отдельной статьи.
Стек технологий
Итак, наш начальный стек получился следующим:
TypeScript
Tramvai — модульный фреймворк от команды Tinkoff для разработки React-приложений, про него отдельно поговорим в следующий раз
Tanstack React Query для работы с апи, идет в Tramvai из коробки
Jest как тестовый фреймворк, React Testing Library как основная библиотека для тестирования и Playwright для user-path сценариев
И, наконец, самое ключевое для разработки, о чем мы сегодня и будем говорить: Feature Slice Design для архитектуры.
Почему FSD?
Наш лид при выборе FSD, как основного архитектурного подхода к разработке нового приложения, полагался на способность FSD структурировать процесс разработки и ограничивать хаос, привнося набор четких правил. Иными словами, ставка была сделана на то, что подход привнесет вместе с собой рамки, которые будут сдерживать расползающуюся в разные стороны паттерны и кодовую базу, а также позволит сохранять легкость поддержки и дальнейшего развития проекта в будущем.
Забегая вперед, скажу, что выбор был сделан правильный - подход себя полностью оправдал. Приведу те плюсы FSD, которые казались мне как разработчику многообещающими в начале цикла разработки. Мы вернемся к каждому из них в конце, чтобы посмотреть, оправдались ли ожидания в итоге. Итак, ожидаемые плюсы:
Четкая структура проекта. Я - большой фанат легко считываемых, логичных, хорошо прописанных и продуманных подходов. Одним словом, люблю и топлю за единообразие всех структур. Легкость чтения приложения, выстроенного на FSD, позволяет быстрее ориентироваться не только нам, авторам приложения, но и помогает новым разработчикам быстрее влиться в проект
Изолированность и модульность. FSD позволяет делить приложение на независимые модули (фичи, сущности и т.д.), что тянет за собой целый ряд плюсов:
Легкость разработки: каждый модуль можно разрабатывать и тестировать отдельно.
Повышение производительности команды: разные разработчики могут параллельно работать над разными фичами/сущностями и т.д.
Уменьшение зависимостей: модульность и изоляция работают на уменьшение рисков появления багов при неизбежных изменениях в коде.
Перечисленное выше благоприятствует быстрой масштабируемости проекта. Правильная декомпозиция позволяет быстро разрабатывать приложение, собирая его параллельными усилиями из небольших обособленных блоков, которые не так сложны в своей сути.
Итерации и цифры
Начнем с основы любого скрамбана – циклов разработки. Поскольку в начале разработки в голове у нас был только прототип всего процесса, мы выбрали классический подход в виде номинальных спринтов длиной в три недели с обязательной ретроспективой в конце.
Сразу договоримся, что именно дальше я буду иметь в виду под «итерацией»: по большому счету это процесс создания одного раздела приложения, который чаще всего сводится к одной странице. Например, в нашем проекте по дизайну у пользователя есть навигационное меню с пятью основными разделами. Создание каждого раздела укладывалось у нас ровно в одну итерацию разработки.
Не буду расписывать весь тернистый путь из успехов и неудач, приведу основные цифры:
Процесс разработки 1.0.0 версии приложения с нуля занял 5.5 месяцев. Речь именно про написание кодовой базы фронта (без учета затрат на бэк, написание и согласование ТЗ и дизайн)
Мы прошли 7 итераций
В среднем три недели на итерацию
3 разработчика + техлид
256 000 строчек кода
Итоговый рабочий флоу у нас вырисовался после 2-ой итерации
Первая итерация
Начнём с того, что рассмотрим с вами вступительную итерацию. Она немного отличается по содержимому от последующих. В рамках нее один разработчик писал процесс аутентификации в приложении, а двое создавали UI-kit проекта с прицелом на переиспользование в других проектах компании.
Т.к. дизайн-система едина и содержит переиспользуемые по проектам структуры, это было хорошей отправной точкой для выделения и вынесения общих компонентов в shared, самый мелкий слой FSD. Самым первым шагом в приложении было формирование папок-хранилищ всех иконок, а т.к. большинство из них используются в немного разных вариантах, писались и функции, возвращающие тот или иной вариант.
Все UI-kit компоненты хранятся у нас по пути shared/ui и абсолютно все представлены в Storybook, т.е. к каждому написаны не только тесты, но и т.н. «стори» Сторибука. Кто не знаком со Сторибуком - это такой инструмент взаимосвязи разработчиков, дизайнеров и тестировщиков, служащий для разработки и визуального тестирования UI-компонентов в изоляции: можно прямо «наживую» менять пропсы компонента в интерфейсе стори, смотреть, как меняется компонент, взаимодействовать с ним и видеть различные его состояния.
Плюс в сторибуке удобно смотреть глобальные переменные дизайн-системы, например, цвета:
Или переменные размера текста:
Флоу разработки
* Маленький дисклеймер:
Вас может удивить название одного из наших слоев – Routes. Это Pages слой в чистом виде, нейминг обусловлен применением file-system роутинга на проекте.
Также обращу внимание, что дизайн на скриншотах может быть не окончательным, т.к. отражает вид раздела на момент его создания.
Этап 1: Анализ требований
Работа над новой страницей (разделом) для нашей команды начинается с изучения:
ТЗ
Дизайн-макета
Ручек бэка
Этап 2: Создание FSD-макета
Следующий шаг – создаем выделенную страницу в excalidraw, делимся с командой, устраиваем созвон и начинаем создавать FSD-макет раздела.
Как видно на скриншоте, мы раскладываем в ряд все макеты по странице, что у нас есть, и начинаем работу: выделяем FSD-компоненты и соотносим их со слоем. Здесь мы видим только визуальную репрезентацию, но, естественно, отдельный компонент в FSD не равен UI-компоненту, поэтому данному этапу и предшествует изучение технического задания, а само разбиение производится во время обсуждения командой, а не в одиночку.
Еще раз обращаю внимание, что разбиение и выделение FSD-компонентов осуществляется ни в коем случае не по визуальной репрезентации или занимаемому на экране пространству, а по смыслу и цели того или иного компонента. Макет в данном случае нужен только для наглядности. Например, фича DeclineOrder со скриншота выше несет за собой гораздо больше, чем кнопка «Отменить заказ», которая вообще может содержаться не в фиче, а храниться, например в виджете OrderStatusPanel. Клик по кнопке, т.е. запуск фичи, поведет за собой изменения разных компонентов, но для наглядности на конкретно этом скриншоте мы обводим только кнопку, понимая, что за ней стоит.
По мере работы над проектом мы решили закрепить разные цвета за разными слоями, например фичи – красные, шаред-слой – синий, ui – зеленый и т.д. Мелочь, но помогает еще быстрее ориентироваться в макете.
Скорее всего идеально соотносить компоненты с их местом в FSD-методологии у вас получится не сразу. Больше всего сложностей по началу возникает с определением, относится компонент к сущности или фиче. В нашем опыте чем дальше мы шли по итерациям, тем быстрее проходил процесс, а компоненты разбивались "правильнее".
Этап 3: Схема страницы в документации
После того, как FSD-макет готов, мы создаем схему страницы в Confluence.
Мы храним такую схему страницы в документации разработки, в разделе структуры проекта, рядом с папками, дублирующими FSD-слои приложения. Что она из себя представляет:
Ссылки на дизайн, макет, URL, используемые методы API
Цель раздела – зачем он вообще нужен пользователю
Далее указывается каждая страница (если их несколько), и под ней ее схема такого вида:
Далее по нисходящей указываются виджеты-фичи-сущности-shared, с описанием текстом (где это нужно), что делает, например, фича, какие методы бэка использует, какой UI содержит внутри
Этап 4: Создание задач и их декомпозиция
Имея на руках схему страницы, мы создаем задачу, нарезаем подзадачи и линкуем их между собой. Основной задачей является разработка страницы целиком, потом двигаемся сверху-вниз по FSD и прилинковываем следующие задачи: так, задачу создания страницы будут блокировать задачи на разработку фичей и сущностей, а их, в свою очередь, задачи на разработку shared-компонентов.
Следуя такому пути, спускаясь (или поднимаясь) по цепочке, разработчикам проще понять, из каких подзадач состоит задача. Плюс всегда можно быстро посмотреть, кто исполнитель задачи.
Отмечу, что критически важно не бояться декомпозировать задачу. Мы не раз сталкивались с тем, что безобидная с виду задача разрасталась на много дней, поэтому стали стараться сразу максимально дробить задачу на более мелкие, насколько это возможно. А это, в свою очередь, зависит от правильного разбиения FSD-макета.
Этап 5: Распределение задач
Когда созданы все задачи, мы созваниваемся командой и распределяем задачи между собой. На этом этапе важно обращать внимание на оценку трудоемкости задачи (часов или сторипойнтов): если задача увесистая по времени – это знак, что лучше ее еще раз декомпозировать на более мелкие. В целом стараемся сделать нагрузку одинаковой для всех разработчиков.
Этап 6: Разработка и тестирование
Далее идет обычный процесс разработки и тестирования.
Этап 7: Ретроспектива
После завершения цикла разработки нужно обязательно провести ретроспективу. Это позволит провести работу над ошибками, понять, что можно улучшить и создать задачи для улучшения процесса разработки прямо на ходу. К ретро мы создаем три раздела доски: что было хорошо, что было плохо и что можно улучшить, и до ретро заполняем первые два, а в процессе – третий раздел.
Итоги
Сложившийся процесс разработки разделов по указанному выше алгоритму существенно помог нашей команде, по каким критериям мы это фиксировали:
Скорость разработки: время разработки каждого следующего раздела сокращалось, несмотря на различную их сложность. Я уже упоминал, что в среднем цикл выходил у нас около трех недель, но первые несколько разделов приближались к четырем неделям, а последние мы делали за 2 недели (не считая тестирования), несмотря на то, что именно они являлись самыми сложными по функционалу в приложении.
Скорость тестирования: первые разделы «размазывались» во времени из-за недостаточной декомпозиции задач, неравномерно распределенной во времени нагрузки QA со стороны фронта, срок полного прохождения тестов и исправлений раздела мог достигать 2+ недель. Последние итерации – 1 рабочая неделя.
Производительность: сам процесс разработки с каждой итерацией становился легче, т.к. мы лишь немного улучшали предыдущий вариант, а работать по готовой схеме, очевидно, лучше, чем импровизировать. На производительность напрямую стала влиять четкая, легко читаемая структура проекта.
Свободное время для борьбы с тех. долгом. Структура проекта стала лучше, производительность разработчиков возросла и в результате мы получили высвободившееся в циклах разработки время, которые стали активно использовать для проведения рефакторинга и написание тех. документации.
Документация проекта для разработчиков. Навряд ли она стала бы возможна без четкой структуры проекта и прописанного процесса разработки. В отличии от проектной документации, схем ТЗ, дизайна, она предназначена только для разработчиков, поэтому воспринимается и читается проще. Подробнее про процесс написания, актуализации, структуры документации и ее положительное воздействие на разработку, пожалуй, стоить поговорить в рамках отдельной статьи.
Итого мы получили готовый, легко масштабируемый на другие проекты (нашей компании и не только) шаблон процесса, который можно брать и использовать «как есть». Абсолютно не претендую на новаторство, т.к. спустя время встречал доклады о похожих процессах у коллег (хороший знак, что мы на верном пути), просто делюсь готовой последовательностью, которая именно в такой конфигурации и порядке хорошо сыграла нам на пользу и может быть полезна вам в разработке ваших FSD-проектов. Напомню, что данный флоу подходит для новых проектов, а в следующий раз я поделюсь опытом перевода готового продукта на FSD.
До скорых встреч! Пишите любые интересующие вас вопросы в комментарии.
Комментарии (19)
Mox
04.01.2025 05:38Я никак не могу понять как fsd соотносится с реальным миром
Сущности вск таки обычно используются в разных фичах, значит они не должны быть описаны как свойства фичи, а что-то ближе к компонетнам
Экран/ страница может принадлежать самым разным фичам - например - где то в процессе мы можем попросить таки юзера зарегистрироваться
Да и само понятие фичи как то размыто. Например - на странице где все мои купленные акции мы добавляем аналитику (и отдельную станицу с полной аналитикой). Это вроде фича, но как она изолируется?
Egor_Pestov Автор
04.01.2025 05:38По порядку:
1. Сущности и есть обобщенные модели, которые предназначены для использования в разных фичах. Это ни в коем случае не "свойства фичи", а скорее компонент, репрезентирующий ту или иную бизнес сущность.
Представим такую бизнес-сущность, как "продукт". У продукта могут быть следующие сущности: "карточка маленькая", "карточка большая", "список продуктов". Так что да, в итоге визуально это будет компонентом.
2. Экран/страница в FSD - page (в нашем случае route). Рут не может "принадлежать" фичам, наоборот, разные фичи включаются в рут. Иерархия в FSD вертикальная и однонаправленная. Горизонтальные взаимоотношения тоже возможны, но про них стоит поговорить отдельно.
Захотим добавить на страницу авторизацию? Добавляем в рут/пейджу фичу авторизации.
3. Тут всегда немного путает нейминг. Мне сильно проще воспринимать и выделять фичи помог совет из одного из докладов по FSD: фича = юзер процесс.
Пример про аналитику не совсем понял. Блок аналитики в малом представлении может быть сущностью, если это полноценная страница - пейдж, либо виджет, тут уже нужно смотреть на конкретный пример. Фича для примера, упоминавшегося выше - это например "оплата", или "добавление в корзину", или "удаление из корзины". В фиче может быть работа с апи и, например, оптимистичная мутация данных на фронте.
clerik_r
04.01.2025 05:381. Сущности и есть обобщенные модели, которые предназначены для использования в разных фичах. Это ни в коем случае не "свойства фичи", а скорее компонент, репрезентирующий ту или иную бизнес сущность.
Иными словами, просто компонент. Но вы зачем-то просто компонент обсыпали кучей лишних слов.
2. Экран/страница в FSD - page (в нашем случае route). Рут не может "принадлежать" фичам, наоборот, разные фичи включаются в рут. Иерархия в FSD вертикальная и однонаправленная. Горизонтальные взаимоотношения тоже возможны, но про них стоит поговорить отдельно.
Захотим добавить на страницу авторизацию? Добавляем в рут/пейджу фичу авторизации.
Причем тут fsd? Это на уровне детского сада понятно.
src/page/SomePage/index.tsxможет в себе содержать все что угодно, но понятное дело чтоsrc/components/AnyCompoentне может содержать в себе страницу. Ведь она то и страница, что это на ней содержатся элементы.3. Тут всегда немного путает нейминг. Мне сильно проще воспринимать и выделять фичи помог совет из одного из докладов по FSD: фича = юзер процесс.
Пример про аналитику не совсем понял. Блок аналитики в малом представлении может быть сущностью, если это полноценная страница - пейдж, либо виджет, тут уже нужно смотреть на конкретный пример. Фича для примера, упоминавшегося выше - это например "оплата", или "добавление в корзину", или "удаление из корзины". В фиче может быть работа с апи и, например, оптимистичная мутация данных на фронте.
Столько проблем на ровном месте, нет чтобы просто по классике все делать, где все просто и понятно. Но нет, надо создать себе кучу геморроя, чтобы на каждый чих 2 часа думать, то ли это feature, то ли это widget, то ли это entity. Ну бред же. И ещё в довесок навешать на себя оков виде всяких ограничений. Никогда не понимал у людей тягу специально страдать.
clerik_r
04.01.2025 05:38Я никак не могу понять как fsd соотносится с реальным миром
Вы всё правильно не понимаете, fsd никак и не соотносится с реальным миром. Это очередная мертворожденная фигня.
Egor_Pestov Автор
04.01.2025 05:38Очередная, как... что например? Как функциональные компоненты в Реакте, которые тоже всех по началу пугали? Вы в FSD разбираетесь и на FSD работали? Применяли ее на своих проектах, метрики какие-то снимали с fsd и с не-fsd? Что-то мне подсказывает, что нет.
Про ограничения - почитайте, зачем в целом архитектура нужна. Я видел судьбу проектов "без всяких ограничений", когда время на поддержку растет пропорционально времени существования проекта и объему кода. Код без ограничений неизбежно превращается в бесформенную массу, какой бы талантливой не была команда.
> fsd никак и не соотносится с реальным миром
Только в ру-сегменте десятки топовых компаний (посмотрите на HH статистику по количеству требований знания/опыта fsd, посмотрите доклады Яндекса, Самоката и т.п.) применяют эту "мертворожденную фигню", видимо, чтобы страдать побольше.clerik_r
04.01.2025 05:38Очередная, как... что например?
Зайдите на npm и посмотрите, тонны мертворожденных стейт менеджеров и т.д. и т.п.
Как функциональные компоненты в Реакте, которые тоже всех по началу пугали?
Нет, они ни в какое сравнение с fsd не идут. В функциональный компонентах реакта сразу явно выделялась очень удобная фича это useEffect, я его сразу же и имплементировал в текущий проект на классовых компонентах. Это был ещё далекий 2018 что-ли, уже даже не помню.
Вы в FSD разбираетесь и на FSD работали?
Да, работал на 2х проектах с ним. Плюс видел примеры. Плюс мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет.
Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы FSD приносил удобство по сравнению с классикой, я бы сразу же перевел все свои проекты на FSD и новые начинал с FSD. Или же если бы redux был удобнее чем mobx, я бы сразу выкинул mobx и перешел на redux. И т.п.Простой пример из жизни, для большинства людей которые видят коровью лепешку на дороге достаточно просто ее видеть, чтобы понять что она не вкусная и вонючая) Для этого нет нужны к ней походить, пробовать ее на вкус и тд)
Или когда ты видишь кипящую воду(она вся такая бурлит) нет смысла совать в нее руку и проверять температуру, ты уже знаешь что это кипяток.
Вот и тут такой же принцип.Можно себе сэкономить уйму времени и нервов, избежав такого рода экспериментов. Просто посмотри что перед тобой, проведи мысленный эксперимент и вуаля.
У меня в отличии от вас позиция не предвзятая и не фанатичная, а просто вытекает из фактов и простых принципов. Всё сугубо ради удобства и выгоды с точки зрения трудозатрат. Зачем мне на проекте применять подход Y, если с ним я в 2 раза больше времени трачу на реализацию таких же задач, как тратил бы если бы использовал подход X.
Например в 2016 году я считал что typescript это оверхед, с 2012 по 2016 ни разу TS не юзал, но в уже 2017 я пересмотрел свою позицию и с тех пор typescript only. До появления async/await в Node.js ноду я тоже не рассматривал в серьез как инструмент для написания бэка. Но JS эволюционировал, стал значительно круче и вуаля, в 2018 я уже писал бэкенд на Node.js с удовольствием.
Про ограничения - почитайте, зачем в целом архитектура нужна.
Я больше 13 лет в коммерческой разработке и уже кучу проектов с нуля реализовал, пересмотрел и перепробовал всё что можно и нельзя.
Я видел судьбу проектов "без всяких ограничений", когда время на поддержку растет пропорционально времени существования проекта и объему кода. Код без ограничений неизбежно превращается в бесформенную массу, какой бы талантливой не была команда.
Вы видели проекты написанные джунами либо отвратительным разработчиками и теперь судите так про все проекты, которые не используют fsd. Вот и всё что вы видели.
Только в ру-сегменте десятки топовых компаний (посмотрите на HH статистику по количеству требований знания/опыта fsd, посмотрите доклады Яндекса, Самоката и т.п.) применяют эту "мертворожденную фигню", видимо, чтобы страдать побольше.
И что? В каждом из этих холдингов сотни проекты, и если на единицах они попробовали это недоразумение, это не значит что всё ппц, надо делать так. Более того, то как пишут в яндексе. сбере, самокате и т.п. это вообще даже не близко нельзя использовать как пример для подражания, там работают обычные разрабы, обычного уровня, не выдающегося. А вы опять апеллируете к авторитетам. это прям невежество. Если самокат и яндекс начнет писать на angular, что будете делать? Побежите писать на angular? А если они начнут на кнопки нажимать левой ногой и сделают доклад о том, как это хорошо, вы тоже будете левой ногой на клавиши нажимать?
illright
04.01.2025 05:38Спасибо за подробное описание вашего опыта, с удовольствием прочту и следующие статьи!
На одном из скриншотов увидел сегмент "hooks", который не рекомендуется создавать по FSD, т.к. это название говорит, "что", а не "зачем". Почему вы решили создать такой сегмент, а не api/model, как по классике?
Ещё интересно, какой фреймворк вы используете, чтоб устроить роутинг через routes/. Большинство файловых роутеров устроены через вложенные папки, что несовместимо с плоской структурой слайсов в FSD. В вашем фреймворке нет возможности переназначить папку роутов на src/app/routes, к примеру? Этот вопрос меня интересует, в частности, и потому, что фсдшный линтер, Steiger, пока не поддерживает переименование слоёв, а может быть, он бы был вам полезен.
И последняя маленькая ремарка — официальное написание — "Feature-Sliced Design", у вас в статье и на обложке немного по-другому :)
Egor_Pestov Автор
04.01.2025 05:38Спасибо за отзыв)
Про хуки - для всей команды это был первый полноценный проект на FSD, поэтому в пути набили какие-то шишки. Оглядываясь назад - действительно, логичнее было бы создавать папки model, куда можно складывать также и апи для горизонтального взаимодействия: кросс-импортов (одна из самых больных тем fsd).
На эту тему мне понравился вот этот доклад с последней HolyJS Александра Моргунова, в нем как раз описывается этот кейс (да и многие другие, с которыми мы столкнулись в итоге)
Для роутинга мы используем Трамваевский file-system routing
Общая структура получается простая и наглядная:
По поводу линтера - затащить его хотелось бы, но подружить его с Трамваем пока что скорее всего не получится.
Касательно написания - действительно, спасибо, поправлю
Alex_D_L
04.01.2025 05:38Мы решились на сразу несколько экспериментов - новый фреймворк (Tramvai), FSD, react-query. И в рамках Tramvai решили попробовать fsr - для себя условились, что routes - будет нашим слоем pages. Вы верно подметили и про Steiger(да - хочется его подключить в будущем) и про то, что иногда приходится создавать вложенные папки для сложных роутов. В целом это нам не помешало и структура FSD сложилась. Tramvai позволяет реализовать не только fsr реализовать - и, возможно, в следующих проектах мы от него откажемся (вопрос открыт)
illright
04.01.2025 05:38Кажется, Tramvai позволяет переопределить папку роутов, не отказываясь от FSR — https://tramvai.dev/docs/features/pages#configuration
Alex_D_L
04.01.2025 05:38Есть такое да - но там мы столкнулись и с другими трудностями fsr - потому с дальнейшим его использованием - еще не определились
markelov69
04.01.2025 05:38По сравнению с традиционной(классической) архитектурой. fsd полная чушь. (позаимствованный скриншот):
Все интуитивно понятно, предельно просто для всех и всегда. Никаких избыточных ограничений и т.п.
Egor_Pestov Автор
04.01.2025 05:38Мне есть с чем сравнивать как в рамках предыдущих, так и в рамках текущих проектов. Наш FSD-проект безоговорочно лидирует по скорости погружения, поддержки и остальным плюсам, указанным в статье.
"Традиционной" архитектурой обычно является ее отсутствие, что приводит к адской неразберихе в корневых папках компонентов/хуков и т.д.
Ограничения существуют в любых архитектурах, и работают они на благо - ценой ограничений создается порядок и легкость поддержки. Чтобы понимать ценность архитектуры как таковой, почитайте какого-нибудь Дядюшку Бо, он в каждой своей книге про это пишет практически.
Голословные утверждения про "просто для всех" конечно хорошо, но опять же, в статье приведены реальные цифры и реальные итоги, опять же, сравнение с другими не-fsd проектами перед глазами.clerik_r
04.01.2025 05:38Голословные утверждения про "просто для всех" конечно хорошо, но опять же, в статье приведены реальные цифры и реальные итоги, опять же, сравнение с другими не-fsd проектами перед глазами.
А у вас не голословные утверждения? Вы говорите что якобы у вас все стало лучше и быстрее. Но это просто слова, которые нельзя проверить. Поэтому написать можно все что угодно в ваших выводах.
"реальные цифры и реальные итоги" что?))
Вот вам реальные цифры и итоги, скорость разработки с fsd падает в 10 раз, удобство падает в 20 раз.
Как вам такие реальные цифры и итоги?почитайте какого-нибудь Дядюшку Бо, он в каждой своей книге про это пишет практически.
А если он скажет с крыши прыгать? Прыгните?
Апелляция к "авторитетам" это смешно. Вы просто решили с какого-то перепугу, что Х говорит дельные вещи, буду слушать то, что говорит Х. Без разницы что я сам думаю, что говорят остальные, только Х это истина."Традиционной" архитектурой обычно является ее отсутствие, что приводит к адской неразберихе в корневых папках компонентов/хуков и т.д.
И где на этом скриншоте отсутствие архитектуры? Где там ад, неразбериха и т.п.?
А вы проекты кроме тех, что писали джуны видели?Наш FSD-проект безоговорочно лидирует по скорости погружения, поддержки и остальным плюсам, указанным в статье.
Ахахах, вот это прикол... Наш сыр безоговорочно лидирует над сырами конкурентов. Наши машины безоговорочно лидирует над машинами конкурентов.
Ваш fsd-проект безоговорочно проигрывает по всем фронтам классическому проекту с архитектурой здорового человека.Egor_Pestov Автор
04.01.2025 05:38Вам fsd дорогу чем-то перешел, что вы с пеной у рта бегаете по fsd-постам и что-то кому-то доказываете? Аж три страницы комментариев по этой тематике на аккаунте с нулем публикаций)
Ну напишите пост какой-нибудь со сравнением одинаковых проектов, написанных на "классической" и fsd-архитектуре в динамике в крупном бизнесе, под ним и поговорим. А дальше вникать в пассажи безработных ноунеймов с синдромом утенка, боящихся не дай бог что-то новое узнать/попробовать не интересно, сорян)clerik_r
04.01.2025 05:38в пассажи безработных ноунеймов с синдромом утенка
Ноунеймов?) Безработных?)) Аххаха. Опять апелляция к "авторитетам", ну это уже за гранью нелепости. А вы как вообще, сами решаете что сегодня поесть или смотрите как один из ваших кумиров запостит то, что он сегодня ел и вы едите тоже самое? Судя по всему сами вы вообще решения не принимаете, только обязательно должен кто-то что-то сказать, написать.
боящихся не дай бог что-то новое узнать/попробовать
Да вы что?
А чего же я пишу на реакте, а не PHP как в 2012 году?
А чего же я пишу на typescript'e вместо javascript'a как писал до 2017 примерно?
А чего это я использую MobX вместо redux который использовал раньше в связке с реактом?
А что же я использую Vite, а не Webpack который юзал в периоде с 2016 по 2021 год?
И т.д. и т.п.
Вы типичный фанатик, а я человек практичный, и не страдаю там, где можно не страдать. Я всегда смотрю на все новое и если вижу что это стоящая вещь, то обязательно ее пробую. И если она лучше того, что есть сейчас, то разумеется без всяких зазрений совести заменю то, что есть сейчас, на то, что лучше и удобнее.
rtatarinov
А зачем вам SSR в закрытом под авторизацией личном кабинете?
Egor_Pestov Автор
Сорри, про SSR упоминание оставалось по ошибке)