Оглавление
Как фронтенд-разработчик, я долгое время работал с классическими архитектурными подходами, где основной фокус был на простоте и скорости разработки. Но когда проекты стали масштабироваться, управление кодом превратилось в сложную задачу, и я начал искать более структурированные решения. Это привело меня к Feature-Sliced Design (FSD), и я хочу поделиться своим опытом перехода на эту архитектуру, как она помогла команде и бизнесу, и с какими проблемами мы столкнулись.
Что такое FSD?
FSD — это методология для фронтенд-разработки, основанная на разделении приложения на фичи и срезы. Основная идея — структурировать проект так, чтобы каждая фича была независимой и легко расширяемой, при этом весь код организован таким образом, чтобы упрощать поддержку и масштабирование.
Проблемы до перехода на FSD
До перехода на FSD в наших проектах были типичные проблемы крупных приложений:
— Сложность масштабирования. По мере увеличения функциональности приложения, архитектура начала трещать по швам. Мы использовали классическую структуру, где код был организован по типам: компоненты, утилиты, стили и т.д. На небольшом проекте это работает отлично, но когда приложение достигло определённого масштаба, мы столкнулись с серьёзными проблемами:
Пример: У нас был модуль авторизации, который по сути был просто одной большой функцией, обрабатывающей множество сценариев (вход через email, вход через соцсети и т.д.). Со временем в него добавлялись новые проверки и логика, и в итоге этот модуль превратился в «монолит», который стало сложно поддерживать и изменять. Любая новая функциональность требовала правок в уже существующем коде, что приводило к частым регрессиям.
Как это влияло на масштабирование: Когда требовалось добавить новую форму авторизации, например, через телефон, изменения касались уже написанного кода. Появлялись риски, что изменения повлияют на другие части приложения, что замедляло процесс разработки и увеличивало количество тестов.
— Низкая переиспользуемость. Наши модули, особенно связанные с бизнес-логикой, были сильно переплетены друг с другом. Из-за этого возникали сложности с повторным использованием кода в других частях проекта или на новых проектах.
Пример: Допустим, в одном из проектов у нас был модуль для работы с заказами. Этот модуль был тесно связан с модулем пользователя, так как при создании заказа нужно было передавать данные пользователя. В результате, при попытке использовать тот же модуль на другом проекте (где структура данных пользователя была немного другой), возникала масса ошибок и зависимостей.
Как это влияло на переиспользуемость: Для каждой новой части кода приходилось копировать логику и адаптировать её, что приводило к дублированию кода и потенциальным ошибкам. Код становился менее гибким и труднее поддерживался.
— Трудности с онбордингом новых разработчиков. Одной из самых заметных проблем был процесс онбординга новых разработчиков. Когда новичок приходил в команду, ему требовалось много времени, чтобы понять, как устроена структура проекта. Причина — отсутствие чёткого разделения фич, бизнес-логики и UI-компонентов.
Пример: В одном из проектов, новый разработчик должен был добавить функциональность фильтрации данных. Он провел несколько дней, разбираясь, где находится логика фильтрации, поскольку часть этой логики находилась в сервисах, часть — в компонентах, а часть — в хелперах. В результате, чтобы реализовать новую функциональность, ему пришлось редактировать несколько модулей, которые не всегда логично связаны между собой.
Как это влияло на продуктивность: Новые члены команды долго «входили в курс дела», что увеличивало время разработки и приводило к частым ошибкам. Разработчики не могли быстро переключаться между задачами, потому что приходилось тратить время на разбор связей между различными модулями и компонентами.
Переход на FSD и решение проблем
Когда мы приняли решение перейти на FSD, наша команда начала с рефакторинга существующих модулей, чтобы соответствовать новым принципам. Мы разделили проект на несколько слоёв:
— App (приложение): глобальная логика и настройки.
— Pages (страницы): уровни приложения, разделённые по основным маршрутам.
— Features (фичи): независимые модули, которые представляют определённые функциональные блоки.
— Shared (общие): переиспользуемые модули, которые не зависят от бизнес-логики конкретных фич.
Пример из практики:
Одна из фич, с которой мы работали, была модуль регистрации пользователей. В предыдущей архитектуре весь код регистрации находился в одном большом файле, что создавало путаницу и ошибки при изменении логики. Мы разделили этот модуль на несколько слоёв:
— UI-компоненты: интерфейс, связанный с полями и кнопками.
— Сервисы: работа с API и валидацией данных.
— Модели: данные о пользователе и его состоянии.
Это позволило ускорить работу с этим модулем и облегчило добавление новых функций, таких как авторизация через социальные сети.
Как FSD помог команде и бизнесу?
— Ускоренная разработка. FSD помог нам разделить код на независимые части, что позволило нескольким разработчикам работать над разными фичами параллельно, не мешая друг другу.
— Уменьшение багов. Логическое разделение кода сделало его более прозрачным и снизило вероятность случайных ошибок.
— Лучшая поддержка и масштабирование. Добавление новых фич стало проще: мы точно знали, где и как они должны быть добавлены в проект. Бизнес мог быстрее реагировать на запросы рынка и внедрять новые функциональности.
— Проще онбординг новых разработчиков. Теперь новички быстро понимали, как структурирован проект, и могли сосредоточиться на конкретных фичах, а не на изучении всей кодовой базы.
Плюсы FSD
— Чёткая структура и масштабируемость. Одним из главных плюсов FSD является строгая и понятная структура проекта. FSD разделяет приложение на независимые модули и слои, такие как фичи, страницы, шаред компоненты и т.д. Это значительно упрощает понимание структуры приложения и добавление новых фич.
Пример: В одном из наших крупных проектов мы реализовывали сложную панель управления с множеством модулей (управление пользователями, заказы, отчеты и т.д.). До внедрения FSD каждый модуль имел сложные зависимости от других, и каждый новый функционал влиял на работу существующего кода. После перехода на FSD, мы смогли разделить эти модули на независимые фичи. Например, фича «управление пользователями» больше не зависела от «модуля заказов», и мы могли безопасно добавлять или изменять любую из этих частей без риска сломать другую.
Как это помогает масштабируемости: Новые возможности добавляются в виде отдельных модулей (фич), которые легко интегрируются в проект. Это позволяет избегать больших изменений в основной структуре приложения и снижает риски появления багов.
— Повышение продуктивности. Одна из сильных сторон FSD — это независимость фич, что позволяет разделять работу между несколькими разработчиками. Каждый разработчик может работать над своей частью приложения, не опасаясь, что изменения в его фиче повлияют на другие части проекта.
Пример: На одном из этапов разработки мы добавляли несколько новых фич одновременно: модуль поиска и фильтрации данных, а также новый отчётный раздел. Благодаря FSD архитектуре, каждый разработчик смог сосредоточиться на своей фиче, не задумываясь о том, что его работа может как-то повлиять на работу другого модуля. Это существенно ускорило процесс разработки, так как мы могли параллельно внедрять несколько новых функций.
Как это влияет на продуктивность: Возможность параллельной разработки разных фич сокращает общее время разработки. Каждый модуль изолирован и независим от других, что снижает количество конфликтов при слиянии кода и улучшает эффективность работы команды.
— Улучшение читаемости кода. FSD делает код более структурированным и логичным. Четкая организация по слоям (страницы, фичи, сущности, утилиты) помогает быстрее ориентироваться в проекте, что особенно важно в больших командах и на крупных проектах.
Пример: В проекте с классической структурой модули часто хаотично перемешивались, и разработчикам было сложно понять, где находится та или иная часть логики. В FSD всё стало гораздо более интуитивным: каждая фича имеет свои компоненты, логику и стили, находящиеся в одном месте. Новые разработчики, приходя в проект, могут сразу увидеть, где находятся UI-компоненты, где бизнес-логика, а где API-запросы, и быстро приступить к работе.
Как это помогает читаемости: Ясная и чётко организованная структура делает код более доступным и понятным. Это упрощает не только работу над проектом, но и процесс его сопровождения, так как любой разработчик может быстро найти нужный модуль и внести изменения.
— Лёгкость переиспользования. Модульность FSD способствует переиспользованию компонентов и сервисов в разных частях приложения. Благодаря строгому разделению фич, бизнес-логика становится более гибкой, что позволяет использовать одни и те же модули в разных контекстах.
Пример: Мы разработали модуль для работы с таблицами данных, который поддерживал сортировку, фильтрацию и пагинацию. Раньше такой функционал приходилось заново реализовывать для каждой страницы, что увеличивало время на разработку. С переходом на FSD, этот модуль был выделен в отдельную фичу и легко переиспользовался на всех страницах, где была нужна таблица с таким функционалом. Это уменьшило дублирование кода и ускорило работу над новыми страницами.
Как это помогает переиспользованию: Фичи, созданные в одном месте, можно быстро адаптировать для использования в других частях приложения. Это позволяет разрабатывать компоненты и логику один раз и использовать их по мере необходимости в разных модулях, что значительно сокращает время разработки.
Минусы FSD
— Крутая кривая обучения. Одним из главных минусов FSD является сложность освоения для тех, кто привык работать с классической монолитной архитектурой. FSD требует кардинально другого подхода к структуре кода, что может занять время для адаптации команды.
Пример: В одной из команд переход на FSD вызвал затруднения, особенно среди разработчиков с опытом работы в классических архитектурах, таких как MVC. Им пришлось переосмысливать привычные паттерны и учиться структурировать проект по фичам и слоям. Это вызывало временное снижение скорости разработки на первых этапах, пока все члены команды не освоили новый подход.
Как это влияет на команду: Процесс перехода требует от команды глубокого понимания принципов FSD и нового мышления в плане организации кода. Время на обучение может замедлить внедрение архитектуры, особенно если проект срочный.
— Увеличение количества файлов. FSD предполагает разделение кода на множество файлов, что значительно увеличивает их количество. Для небольших проектов это может оказаться неэффективным, так как возникает ощущение «раздутости» структуры.
Пример: В небольшом проекте, который разрабатывала наша команда, количество файлов выросло более чем в два раза после перехода на FSD. Например, для простой формы регистрации пришлось создать несколько файлов для каждого уровня: компонент, бизнес-логика, модели данных и т.д. В итоге поддержка небольшого проекта стала сложнее, поскольку приходилось постоянно переключаться между множеством мелких файлов.
Как это влияет на проекты: Для малых или средних проектов FSD может привести к излишней фрагментации кода, что затрудняет его поддержку и усложняет навигацию.
— Мелкие фичи могут усложнить структуру. В FSD важно правильно масштабировать проект. Если перегнуть с количеством слоёв и модулей, можно запутаться в излишней абстракции. Маленькие фичи могут быть излишне раздроблены, что создаёт сложности в поддержке и понимании структуры.
Пример: В одном из наших проектов каждая фича разбивалась на множество маленьких модулей, что создавало чрезмерно глубокую структуру. Простая функция, такая как фильтрация данных, была разделена на несколько файлов, что привело к необходимости постоянно переходить между ними для понимания, как всё работает вместе. Это увеличивало время на изменения и затрудняло поддержку кода.
Как это влияет на масштабируемость: Если неправильно организовать архитектуру, можно перегрузить проект множеством небольших файлов и слоёв. Это особенно проблематично для проектов с небольшим объёмом кода, где такие уровни абстракции могут быть излишни.
Заключение
Переход на FSD был для нас значимым шагом, который решил множество проблем, связанных с масштабированием и поддержкой крупных проектов. Хотя вначале были трудности с адаптацией, в долгосрочной перспективе эта архитектура принесла значительные выгоды как для команды разработки, так и для бизнеса.
FSD — это отличный выбор для крупных и растущих проектов, где важна чёткая структура, высокая переиспользуемость кода и возможность быстрого масштабирования.
Комментарии: