Абсолютная свобода в организации кода — бич любого проекта на React, что затрудняет переход разработчиков от проекта к проекту. Архитектурные подходы призваны решить эту проблему. Однако не все так просто, когда нужно за 1 спринт внедрить какую-либо систему правил структурирования кода в проект, который активно развивается, эксплуатируется внутрикорпоративным заказчиком и не имеет права упасть. О том как нам это удалось, я и расскажу в этом посте
Про проект, не нарушая NDA
Я пришел на этот проект несколько месяцев назад и начал с того, что выяснил его историю. Как оказалось, первые пару лет его писал очень талантливый разработчик в одиночку. Без какого-либо код-ревью.
Проект был идеальным стартапом — работал, приносил выгоды и не требовал особого внимания, технической и околотехнической возни. Он мирно обрастал техдолгом ровно до тех пор пока не потребовалось масштабировать его.
Когда же эта задача возникла — к нему стали подключать новых разработчиков, в том числе и меня. Свежим, незамыленным взглядом, мы увидели некоторые проблемы в том как организован код. Например, компонент очередной таблицы можно было найти примерно по такому пути (бизнесовую логику скрыл за плейсхолдерами, обрамленными %)pages/%USER_ROLE%/pages/components/%FEATURE_NAME%/%TABLE_WE_WANT%
Поиск нужного куска кода мягко говоря доставлял боль и, посовещавшись, мы решили навести порядок
Выбор архитектуры. Или почему мы остановились на FSD
Ресерчем занимался я, поэтому сначала обсудил ряд требований с коллегами. Остановились на том что хотим, чтобы новая архитектура была
- Расширяемой, чтобы мы могли переварить любое возможное масштабирование
- С четкими архитектурными границами, чтобы мы понимали какие компоненты куда размещать
- Кричащей, чтобы структура явно сообщала о функциональности и возможностях приложения
- Простой для внедрения, потому что мы хотим плавно переехать, а не ковырять проект три спринта, все разломать, ничего не добиться и откатиться назад
Это сильно упростило ресерч, сильно сузив пространство вариантов. По честному, после определения требований, выбор остался такой: оставить как есть и привыкать, переделать на модули, внедрить FSD.
Первое — отмели сразу, а вот между модулями и FSD выбрали последнее потому что в ней меньше вольнодумства, а значит знакомый с правилами такого дизайна разработчик быстрее сможет освоиться на нашем проекта. Да и мы сэкономим время онбординга, просто скинув ему документацию по этой архитектуре.
Внедрить и не разломать
Официальная документация предлагает сначала выделить слои app и shared, а далее постепенно наполнять промежуточные. Это не наш метод. Мы хотели более быстрых и ярких перемен. Поэтому сразу же растащили код по соответствующим слоям. Однако прежде договорились о следующем
- Основная задача на период перехода – внедрить слои и начать группировать код по смыслу
- Слой widgets существует, но основная рабочая директория – features, далее отделим крупные комплексные фичи в виджеты
- Пока действует предыдущее, разрешаем одним фичам импортировать другие
- Сегменты в слайсах – опционально
- Линтеры на FSD настроены на severity – warning
- Прощаем себе и старому коду нарушение правил
Отдельно про слой widgets — мы внедрили такое правило, потому что у некоторых разработчиков не было четкого понимания чем они отличаются от features и почему их стоит выделять. Мы же решали задачу плавного и понятного внедрения. Сегодня, спустя пару месяцев, мы уже полноценно используем все слои архитектуры.
Какой эффект мы получили
Если честно, пока рано судить. Переходный период не закончен, однако могу выделить следующие преимущества, которые заметил я и о которых рассказали мне коллеги
- код начал консолидироваться по фичам, то есть постепенно слой с той или иной фичей расширяется теми компонентами которые нужны только лишь ей
- параллельно с нами рефакторится бэкенд, изменяются контракты и мы легко и быстро внедряем эти изменения
- активно вычищается дублированный код, который ранее был размазан по разным директориям
- мы получили понятный способ декомпозировать рефакторинг других проблемных мест
Дальше мы будем закручивать для себя гайки, тонко настроим линтеры (может напишем свои), помогать с переходом на FSD соседним проектам. К старой стихийной архитектуре откатываться не будем. Это единогласно. И это хорошо.
