Неделю назад прошла конференция «Я 💛 Фронтенд 2024», на которой я в качестве спикера рассказывал про архитектурную методологию Feature-Sliced Design. На отдельные ролики еще не нарезали, но есть запись трансляции всей конференции с разбитыми таймингами по докладам. Как выложат отдельное видео, скину его сюда. Уже давно хочу поделиться некоторыми мыслями насчет конференций (за последний год был на нескольких митапах, FrontendConf и CodeFest), что движение идет куда-то не в ту сторону. Часть с докладами уходит на второй план и уступает стендам партнерских компаний и охотой за мерчем. В ближайшее время соберу все вместе и закину свои рассуждения на этот счет. Что касается моего выступления. Рассказал что из себя представляет методология FSD (= архитектурные паттерны + правила по неймингу структуры проекта), основные сложности при использовании (= нужно знать архитектурные принципы, многие вещи методология не регламентирует, интегрировать в существующий проект практически нереально). Далее на примере разобрали основные слои и перешли к проблемам: кросс-импорты, зависимости на разных слоях (которые решаются инверсией), нехватка слоев. Несколько вещей, которые хочется отметить отдельно: 1️⃣ Было много хороших вопросов в чате, на какую-то часть ответил со сцены, на другие постарался ответить в чате конференции. Про микрофронты, про редакс со своим моностором, про внедрение в существующие проекты, про внедрение в компанию в целом, про то, можно ли замерить эффективность использования FSD. Может как-нибудь соберу все вместе и сделаю контрибьют в документацию FSD в раздел вопросов/ответов. 2️⃣ В чате написали, что как будто доклад про то, почему FSD не стоит использовать, сильно много проблем, которые приходится решать. На самом деле посыл был не такой. Проблемы есть у каждой методологии/фреймворка, FSD не исключение. Я мало говорил о достоинствах (и возможно зря), так как был сильно ограничен таймингами. Хотелось поделиться именно сложностями на основе реального опыта (считаю это самой интересной частью) и путями их решения. Через расширение методологии (местами через экспериментальные фичи) можно решить практически все, поэтому как минимум к изучению методологию точно рекомендую 👍 3️⃣ Про новый линтер. Пару недель назад core-команда анонсировала новый архитектурный линтер steiger, который выложили на гитхаб через несколько дней после выступления. Проект еще в статусе активной разработки, но у него очень большой потенциал. Его можно использовать и за пределами FSD, или использовать только те правила, которые релевантны для вас. Каждое правило - это обычная функция, в которой с помощью готовых хелперов можно делать самые разные проверки на директории, файлы или импорты внутри (например, правило проверки отсутствия публичного API у слоев https://github.com/feature-sliced/steiger/blob/master/packages/steiger-plugin-fsd/src/no-layer-public-api/index.ts#L5-L19). ESLint сильно ограничен по словам ребят, поэтому решили делать с нуля. Тут важно отметить, что FSD в первую очередь про архитектуру, на основе которой уже получается определенная структура проекта. Линтер - это про структуру. Но с соблюдением структуры (через линтер) можно следить за тем, что бы не нарушать архитектуру. С одной стороны замкнутый круг получается, с другой - хороший линтер будет помогать и с архитектурой, и со структурой проекта. P.S. Все ребята, которые были офлайн и подходили задавать вопросы, подискутировать по FSD и в целом про фронтенд, спасибо вам! Был очень рад со всеми пообщаться)