22 y.o. front-end developer with a special love for learning and creating
This story contains new, firsthand information uncovered by the writer.
The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)
This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.
Фронтенд-разработчики часто сталкиваются с проблемой, связанной с архитектурой приложения. Это требует использования архитектуры, которая может легко масштабироваться и обеспечивать слабую связь и высокую связанность между модулями приложения.
В этой статье рассматривается архитектура Feature-Sliced Design, поскольку, на мой взгляд, она является лучшей среди доступных вариантов. В нем также исследуется идея FSD и проблемы, которые решает эта архитектурная методология.
Мы сравним FSD с классической и модульной архитектурой и рассмотрим их плюсы и минусы.
Прежде всего, давайте различать три понятия: слой, срез и сегмент.
Слои, фрагменты, сегменты
Уровни — это каталоги верхнего уровня и первый уровень декомпозиции приложения. Их количество ограничено — максимум 7 слоев — и стандартизировано, хотя некоторые из них являются необязательными.
В настоящее время выделяют следующие слои:
Слои
Эти уровни помогают организовать базу кода и создать модульную, поддерживаемую и масштабируемую архитектуру.
Слои Github
Одной из ключевых особенностей Feature-Sliced Design является его иерархическая структура. В этой структуре сущности не могут использовать функциональные возможности функций, поскольку функции находятся выше в иерархии.
Аналогично, функции не могут использовать компоненты виджетов или процессов, поскольку слои выше могут использовать только слои ниже. Это сделано для поддержания линейного потока, направленного только в одном направлении. Структура слоев
В каждом из слоев есть подкаталоги — слайсы — второй уровень декомпозиции приложения. В срезах связь осуществляется не с абстрактными вещами, а с конкретными бизнес-сущностями. Основная цель срезов — группировать код по его значению.
Имена срезов не стандартизированы, так как напрямую определяются бизнес-направлением проекта. Например, в фотогалерее могут быть такие разделы, как фото, альбом и галерея. Социальная сеть потребует таких фрагментов, как сообщения, пользователи и ленты новостей.
Близко связанные фрагменты могут быть структурно сгруппированы в каталоге, но они должны соответствовать тем же правилам изоляции, что и другие фрагменты — не должно быть общего доступа к коду в этом каталоге.
Ломтики
Каждый срез состоит из сегментов. Сегменты помогают разделить код внутри фрагмента в зависимости от его назначения. В зависимости от договоренностей команды сегменты могут меняться по составу и названию. Чаще всего используются следующие сегменты:
Каждый срез и сегмент имеет общедоступный API. Public API представлен файлом index.js или index.ts, который позволяет извлечь из среза или сегмента наружу только необходимую функциональность и изолировать ненужную функциональность. Индексный файл служит точкой входа.
Правила для публичного API:
Public API упрощает работу с импортом и экспортом, поэтому при внесении изменений в приложение нет необходимости менять импорты везде в коде.
Публичный API
Чем выше уровень, тем больше он привязан к конкретному бизнес-узлу и тем больше бизнес-логики он содержит. Чем ниже уровень, тем больше на нем абстракций, возможности повторного использования и отсутствия автономности.
Абстракция слоев
Одна из задач Feature-Sliced Design — добиться слабой связи и высокой связности. Важно понять, как FSD достигает такого результата.
В ООП эти проблемы уже давно решаются с помощью таких концепций, как полиморфизм , инкапсуляция , наследование и абстракция . Эти концепции обеспечивают изоляцию, возможность повторного использования и универсальность кода, при этом в зависимости от того, как используется компонент или функциональность, получаются разные результаты.
Функциональный дизайн помогает применить эти принципы во внешнем интерфейсе.
Абстракция и полиморфизм достигаются за счет слоев. Поскольку нижние уровни являются абстрактными, их можно повторно использовать в более высоких слоях, и в зависимости от условий компонент или функциональность могут работать по-разному в зависимости от заданных параметров или реквизитов.
Инкапсуляция достигается посредством Public API, который изолирует ненужное извне в срезах и сегментах. Доступ к внутренним сегментам среза ограничен, а общедоступный API — единственный способ получить доступ к функциям и компонентам среза или сегмента.
Наследование также достигается посредством слоев, поскольку более высокие уровни могут повторно использовать нижние уровни.
Я думаю, вы много раз сталкивались с классической архитектурой. Большинство авторов используют его в образовательных статьях и видеороликах на YouTube из-за его простоты. Для классической архитектуры не существует определенного стандарта. Однако часто можно увидеть следующий формат:
Классическая Архитектура
Классическая архитектура подходит для небольших проектов без текущего обслуживания или домашних проектов.
Функциональный дизайн благодаря своим концепциям и стандартам предотвращает проблемы классической архитектуры.
Однако уровень понимания и навыков разработчиков, работающих с FSD, должен быть выше, чем при работе с классической архитектурой. Обычно разработчики с опытом менее 2 лет о FSD не слышали.
Однако при работе с Feature-Sliced Design проблемы необходимо решать «сейчас», а не «позже». Проблемы в коде и отклонения от концепций становятся очевидными сразу.
Простая модульная архитектура имеет ряд недостатков:
Кажется, что в любых сложных или умеренно сложных проектах Feature-Sliced Design следует отдавать предпочтение простой модульной архитектуре. FSD решает множество фундаментальных архитектурных проблем и имеет мало недостатков.
С точки зрения простоты и скорости разработки простая модульная архитектура может иметь преимущество перед FSD. Если необходим MVP или разрабатывается недолговечный проект, простая модульная архитектура может оказаться более подходящей, чем FSD. Но в любом другом случае функциональный дизайн выглядит предпочтительнее.
FSD — молодая архитектурная методология. Однако его уже используют многие банковские, финтех-, B2B-компании, компании электронной коммерции и другие. Вот ссылка на выпуск GitHub со списком компаний: GitHub Issue .
Репозиторий GitHub с официальной документацией FSD на момент публикации этой статьи имел более 1,1 тыс. звезд. Документация активно расширяется, а команда разработчиков и сообщество FSD в Telegram и Discord доступны круглосуточно и без выходных, чтобы помочь людям с вопросами, связанными с архитектурой.
Потенциал этой архитектуры высоко ценится, и ее использование широко распространено среди крупных компаний по всему миру. При правильном внедрении FSD может стать доминирующим архитектурным решением в области внешней разработки.
Feature-Sliced Design — интересное и ценное открытие, которое фронтенд-разработчики должны знать и уметь использовать. FSD может предоставить командам гибкую, стандартизированную и масштабируемую архитектуру и культуру разработки. Однако использование положительных сторон методологии требует знаний, осведомленности и дисциплины внутри команды.
FSD выделяется среди других архитектур благодаря четкой бизнес-ориентации, определению сущностей, функциональному составу и составу компонентов приложения.
Вы также можете самостоятельно изучить примеры использования FSD в проектах и официальную документацию Feature-Sliced Design:
Пример. Магазин кроссовок и обуви Nike
Этот пост может быть длинным, но я надеюсь, что вы узнали что-то новое. Я ценю, что вы дочитали этот пост.
Если у вас есть какие-либо мысли или вопросы, не стесняйтесь оставлять комментарии!
Также опубликовано здесь