Недавно я написал маленькую заметку про наши договоренности при переходе на FSD. В ней сказано лишь то КАК мы переходили, но ПОЧЕМУ мы решили выбрать именно FSD — осталось загадкой. Я упомянул лишь, что мы хотели расширяемую, кричащую архитектуру с четкими границами. Сегодня же поговорим чуть подробнее про кто, за счёт чего всё это достигается. Поговорим и закроем тему (по крайней мере на какое-то время).
FSD увеличивает связность, уменьшает зацепление
Разберемся с понятиями. Я не академик, поэтому разберемся буквально на пальцах, ведь именно так я объяснил эти концепции себе.
Если представить, что кисть нашей руки — один из десятков слайсов какого-то великого приложения, то он являет собой пример идеально высокой связности и низкого зацепления.
Например, если вам нужно внести изменения в дизайн правой руки (например — надеть перчатку), то при должной сноровке и если вам больше 5 лет, вы сделаете это без затруднений, не использовав при этом пальцев левой ноги. Потому что весь «код» этого «слайса» отличается высокой связностью. Он расположен в одном месте, рядом. Грубо говоря, все пальцы правой руки находятся на правой руке. К сожалению, в наших проектах это далеко не всегда так. И с этим помогает побороться FSD.
Теперь рассмотрим кисть как слой приложения, а слайсами будут уже пальцы. В таком случае, если вы хотите внести более точечные изменения, например — набить на первой фаланге среднего пальца блатную татуировку, то вы сделаете это, не затронув ничего лишнего. Не будет такого, что чернила вдруг окажутся под кожей на запястье (если тату-мастер будет трезв и компетентен, конечно). Это происходит потому, что «код» слабо зацеплен. Изменения не расходятся по нему как круги по воде.
В идеальном мире, в котором проект написан на FSD с нуля и с полным соблюдением рекомендаций методологии, все модули плотно связные и слабо зацепленные. Тем же, кто живет в суровой реальности приходится говорить лишь о тенденциях. Используя предложенные подходы, мы лишь делаем единый по смыслу код более связным, а различные бизнес-фичи менее зацепленными. И на том спасибо
За счёт этого достигается расширяемость и живучесть проекта.
FSD делает код самодокументируемым
Нечто похожее привносит и TypeScript, однако это надмножество добавляет свойство только лишь технической самодокументируемости. Благодаря нему вы, как разработчик, понимаете с какими интерфейсами и контрактами работает приложение. Однако TypeScript не документирует почти ничего, что касается бизнес-фичей. Иными словами, язык в императивном стиле указывает на то «как работает», но почти не дает декларативного описания «что оно делает». И тут на сцену выходит FSD.
Представим, что мы открыли код какого-нибудь магазина, написанного в идеальном мире по законам FSD, и знакомимся с тем что там есть. Мы будем двигаться по слоям от верхнего к нижнему, пропустим app и widgets, но попробуем разобраться с тем что же нам досталось от прошлых поколений разработчиков
- Открываем
pages. «Ага, у нас есть четыре основные страницы, на которых работает пользователь. Это витрина товаров, карточка одного товара, страница с историей заказов и некий FAQ. Наверное будет полезно его почитать и мне» - Открываем
features. «Судя по всему наш пользователь может оформлять заказы, писать отзывы к товарам, отправлять жалобы, открывать споры, задавать вопросы. Уф, и еще много всего…» - Открываем
entities. «Получается, что система работает со следующими объектами. Товар, продавец, покупатель, отзыв. Лаконично. Здорово. Нравится» - Открываем
shared. «Ого, похоже в проекте свой UI-kit, надеюсь не костыльный и кастомизируемый. А вот утилит своих почти и нет, разве что несколько хуков. Вот и славненько. Пойду пить кофе»
Итого, за пять минут мы поняли с чем имеем дело. Если слайсы еще и названы корректно, то мы сможем прочитать проект как коротенький рассказ. Это ли не мечта?
FSD возводит четкие границы
То что прекрасно для MVP, губительно для проекта который хочет жить и развиваться хотя бы несколько лет. И та свобода, которую дает наш любимый React (из-за которой его обзывают библиотекой в том числе и сами разработчики), требует установления договоренностей о правилах хотя бы на уровне команды
FSD же устанавливает правила размещения и организации кода на уровне индустрии. В том идеальном мире, о котором я не перестаю рассказывать, мы должны иметь возможность писать на React если не одинаково, то по единым правилам, чтобы понимать друг друга. И эта архитектурная методология дает такую возможность.
При этом, за счёт довольно высокого уровня абстракции и рекомендательного подхода, она может быть использована на ряде совершенно разных проектов. Разных по бизнес-домену, сложности, размеру. Хотя, для совсем уж крохотных приложений — это, конечно, оверхед.
Так или иначе, код получается разграничен достаточно чётко, но физических границ нет. Как будто что-то вроде Шенгенской зоны. Свободные перемещения слайсов между слоями — та практика, которую разрешили себе мы, и которая совершенно необходима для того чтобы поставить большое наследие на новые рельсы.
А как далеко мы на них поедем — покажет время.
