Структура frontend-приложений. Миф или реальность?

Привет, меня зовут Александр Шальнев. Я фронтенд-разработчик в компании Флайкод. В этой статье я хотел бы затронуть архитектуру frontend-приложений.

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

Со временем роста веб-индустрии начали развиваться такие архитектурные подходы, как Atomic Design, Feature Based, Vertical Slices. Мало кто о них слышал и применял, но в конечном итоге компонентно-контейнерный подход стал всеобщим любимчиком фронтенд сообщества. Почти в каждом проекте нас преследовали 3 заветные папки: «components, modules/pages and utils/helpers» и огромная лесенка из компонентов, в которых можно было утонуть. В процессе роста проекта в нем становится все больше логики, которая начинает «расплываться» по коду. Папка components становится слишком большой, туда начинает попадать все от ui-kit’а вашего приложения, до каких-то общих абстрактных компонентов, которые используются во всем приложении и могут достигать 1000 строк в длину. В последствии рефакторинг таких модулей оказывается непосильной задачей даже для самого опытного разработчика. Но выход есть.

Хочу поделиться с вами относительно новым архитектурным подходом, который никого не оставит равнодушным. Feature-Sliced Design (FSD) — это архитектурная методология для проектирования frontend-приложений. Проще говоря, это свод правил и соглашений по организации кода. Главная цель методологии — сделать проект понятным и структурированным, особенно в условиях регулярного изменения требований бизнеса. Данная архитектура будет полезна для средних и больших проектов, которые будут в вашем распоряжении несколько лет. Однако, если у вас уже имеется проект каких-либо размеров, не стоит беспокоиться. Вы так же сможете, хоть и чуть дольше, если бы писали с нуля, отрефакторить ваше приложение на новую архитектуру (как это сделать смотреть в документации). Благодаря правильно заложенному фундаменту вашего приложения вам будет удобно, а главное быстро в нем работать и разрабатывать новые фичи, чему несомненно будет рад ваш бизнес. Одна из главных особенностей этого подхода - методология не привязанная к конкретному языку программирования, UI-фреймворку или менеджеру состояния — подойдет абсолютно любой. Одним из минусов является высокий порог входа. Разработчик должен понимать как работает этот подход и при разработке очередного модуля вам придется подумать (а как думать?) о правильности его расположения.

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

В конце хочу поделиться с вами полезными ссылками, в которых вы можете более конкретно познакомиться с данной архитектурой проектирования.

- Документация методологии. Она все еще находится на стадии написания, но там уже сейчас есть достаточно информации для начала работы.

- Чат в телеграмме. Чат для обсуждения каких-либо вопросов, связанных с методологией. Там находится вся основа команды разработки. Вы можете без проблем задать вопрос, на который вам всегда ответят (сам задавал не раз).

⁃ Доклады на ютубе.

Спасибо за внимание)