Релиз FSD 2.1! Обсуждаем с кор-тимой FSD плюсы и минусы

• Обсуждение темы фичеслайс версии 2.1.  

• Представление Льва, который имеет прямое отношение к изменениям.  

• Лев занимается менеджментом контрибьюшинов, развитием линтера Stager и документацией.  

• Предпочитает улучшать документацию, считая, что в этом направлении много возможностей для улучшения.  

• В команде три человека: Лев, Антон Медведев и Сергей Сова.  

• Антон и Сергей не могут активно заниматься менеджментом, поэтому Лев взял на себя большинство ролей.  

• Год назад была проведена реструктуризация команды.  

• Большая команда тормозила развитие из-за отсутствия активных участников.  

• Решение оставить только наиболее активных участников.  

• Участники, вышедшие из активного состава, остаются в комьюнити.  

• До версии 2.0 развитие было медленным из-за фундаментальных задач.  

• Фиксация базовых определений, таких как слои Entities и Features, стала ключевым шагом.  

• После фиксации определений началось активное развитие.  

• Лев занимается проектом на энтузиазме, совмещая с основной работой.  

• Не хочет ограничивать доступ к знаниям через платные курсы.  

• Инициатива по созданию официального курса по FSD не удалась.  

• Переход от излишней декомпозиции к декомпозиции только по необходимости.  

• Стандартизация экспериментального синтаксиса для кросспортов.  

• Улучшения в потоках.  

• Пейджис Ферст позволяет не декомпозировать пейджи.  

• Проблема чрезмерного копли возникает из-за множества модулей и связей.  

• Предложение FSD: можно не декомпозировать пейджи, если это не требуется.  

• Фича — это взаимодействие пользователя с приложением.  

• Сущность — это подлежащее в предложении, описывающее действия приложения.  

• Не каждая сущность или фича должна быть вынесена в глобальный неймспейс.  

• Подчёркивается важность правильного определения сущностей и фичей.  

• Не все сущности и фичи должны быть частью глобального неймспейса.  

• Ранее использовались однозначные критерии для декомпозиции, но они не всегда применимы.  

• Критерии часто приводят к избыточному коду и сложностям в понимании архитектуры.  

• Эвристики, лежащие в основе FSD, могут давать сбои при большом количестве связей между элементами.  

• Слои сущностей и фич сложны для понимания из-за расплывчатости определений.  

• Для правильного понимания нужно смотреть на приложение с точки зрения бизнеса, а не только разработчика.  

• В команде часто возникают разногласия из-за различий в восприятии бизнес-сущностей и программистских концептов.  

• Разногласия могут стимулировать команду к более глубокому пониманию архитектуры.  

• Процесс споров помогает синхронизировать понимание архитектуры и улучшить декомпозицию.  

• Пример проекта показывает, что после трёх месяцев споров команда смогла достичь единого понимания.  

• Основные преимущества FSD: однородность, устойчивость к изменениям, контролируемое переиспользование логики, ориентация на потребности бизнеса.  

• Эти преимущества требуют более глубокого объяснения для понимания их реализации в приложении.  

• Важно объяснить, как декомпозиция кода обеспечивает устойчивость к изменениям и рефакторингу.  

• Раздел документации, объясняющий методологию FSD, недостаточно проработан.  

• Приоритеты разработки документации часто смещаются в сторону более актуальных тем.  

• Проблема понимания методологии остаётся актуальной и требует внимания.  

• Кричащая архитектура предполагает явное выражение архитектурных решений в структуре проекта.  

• FSD предоставляет рамки для архитектуры, но не определяет её полностью.  

• В старых версиях FSD информация о доменной модели была явно выражена в структуре проекта.  

• Новые версии FSD позволяют лучше понять взаимосвязи между сущностями через кросс-импорт.  

• ФСД предоставляет много информации о проекте через структуру папок.  

• Сущности, кейсы, виджеты и пейджи помогают понять структуру приложения.  

• Проблема: сущности могут быть разбросаны по разным слоям, что усложняет понимание проекта.  

• Часть фичей и сущностей не выражена в структуре папок.  

• Код распределяется по нескольким уровням абстракции, теряя жёсткость критериев декомпозиции.  

• Возникает проблема переиспользования кода и его перемещения между уровнями.  

• Качество информации зависит от навыков декомпозиции в команде.  

• На ранних стадиях проекта важнее построить ментальную карту экранов и переходов.  

• Информация о страницах более полезна для понимания приложения, чем о сущностях и фичах.  

• ФСД ограничен по масштабируемости, особенно при росте приложения.  

• Попытка объединить слабо связанные разделы в один рут ФСД приводит к конфликтам.  

• Решение: разделение приложения на несколько рутов ФСД.  

• Монорепозитории помогают организовать несколько рутов ФСД.  

• В каждом руте могут быть свои слои, например, пейджи и виджеты.  

• Головной пакет соединяет все мини-приложения.  

• Ограниченные контексты — это слабо связанные части приложения с собственным набором терминов.  

• Разделение по ограниченным контекстам создаёт удобные технические модули.  

• ФСД не подходит для приложений с несколькими ограниченными контекстами.  

• Фичерс фест позволяет использовать фичи как ограниченные контексты.  

• Фичи обозначают набор функциональности, слабо связанный с другими кусками функциональности.  

• Модульная архитектура позволяет масштабировать приложение без добавления монорепозиториев.  

• Необходимо стандартизировать концепцию ФСД для разных объёмов приложений.  

• Для больших объёмов рекомендуются модули, монорепозитории или микросервисы.  

• Сложность определения объёма приложения связана с количеством слабо связанных кусочков.  

• Размер приложения не является надёжной метрикой для оценки его сложности.  

• Хорошо построенное приложение с низким колингом может казаться маленьким, но быть сложным внутри.  

• Чрезмерный колинг может сделать даже небольшое приложение огромным.  

• Фронтенд часто сложнее бэкенда, но это не всегда так.  

• Разделение приложения на домены может упростить работу с сущностями и фичами.  

• Импорты работают лучше, когда сущности принадлежат одному домену.  

• В маленьких приложениях архитектурные границы FSD могут мешать, а не помогать.  

• Для маленьких приложений можно использовать паттерны, такие как «пейджис ферст» FSD.  

• FSD стандартизирует структуру проектов, улучшая передаваемость знаний.  

• Однако FSD может быть слишком сложным или простым для большинства проектов.  

• Предлагается создать набор стандартных сборок FSD для разных типов проектов.  

• Это позволит выбирать подходящую архитектуру без необходимости её модификации.  

• Большинство применений FSD неэффективны из-за несоответствия требованиям проекта.  

• Лучше создавать точечные архитектуры под конкретные требования, чем использовать общую архитектуру.  

• Для проектов с несколькими командами могут потребоваться доменные или микросервисные FSD.  

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

• FSD — это набор паттернов, которые формируют структуру проекта.  

• Даже если проект состоит из монорепов с FSD, это всё равно FSD.  

• ФСД рассматривается как набор паттернов, которые можно использовать по-разному.  

• Главная цель ФСД — кристаллизовать архитектурные мысли в практическую структуру.  

• Изменения в документации ФСД должны быть практически применимыми.  

• Горячий раздел ФСД — гайды по конкретным темам, таким как авторизация и типы данных.  

• Практическая применимость ФСД важна для достижения его целей.  

• Обсуждение гайда по TypeScript и вопросов к нему.  

• Обучение реализации функциональности с использованием паттернов ФСД.  

• ФСД должен учить людей писать лучший код, а не просто программировать.  

• Объяснение абстрактных концепций, таких как инверсия зависимости, для улучшения понимания.  

• Проблема применения конкретных знаний в разных ситуациях.  

• Абстрактные концепты могут быть более эффективными для обучения.  

• ФСД имеет теоретическую и практическую стороны.  

• Претензии к ФСД связаны с его неполной формулировкой концептов.  

• Необходимость чёткого определения принципов ФСД.  

• Принципы ФСД помогают объяснять практические решения.  

• Важность чёткой формулировки принципов для лучшего понимания.  

• Возможность формулирования теории на основе принципов ФСД.  

• Ограниченность ресурсов для улучшения документации ФСД.  

• Приоритет в преподавании ФСД — поддержка новичков.  

• Возможность создания видеороликов для лучшего объяснения концептов.  

• Сложность убеждения команды в необходимости ФСД.  

• Признаки, указывающие на необходимость перехода на ФСД: сложности для новых членов команды, частые поломки при изменениях, трудности с добавлением новой функциональности.  

• Стандартизированная архитектура может помочь решить эти проблемы.  

• Проблемы проекта могут указывать на необходимость рефакторинга.  

• ФСД — одно из предложений для рефакторинга, но не единственное.  

• Задокументированность ФСД делает его лёгким способом достижения рефакторинга.  

• Упоминание о вопросах из чата, связанных с авторизацией на Next.js.  

• Обсуждение различий между FSD и Feature-Based архитектурой.  

• FSD рассматривается как более применимая на практике архитектура по сравнению с Feature-Based.  

• FSD — единственная описанная богатая архитектура в фронтенде.  

• Другие архитектуры могут лучше подходить для конкретных проектов, но часто не имеют достаточной документации.  

• Сообщество вокруг FSD большое и активное.  

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

• Пример кастомной архитектуры: «моя версия FSD».  

• Стандартизированная архитектура FSD против индивидуальных архитектур.  

• Описание проблемы: отсутствие единой архитектуры в проектах.  

• Начало внедрения FSD для большого клиента.  

• Трудности с декомпозицией и инкапсуляцией модулей.  

• В подходе Local First кросс-импорты не являются проблемой в рамках одного слайса.  

• Оптимизация удаляемости кода важнее его переиспользуемости на ранних стадиях проекта.  

• Важность код-ревью для изменений в Sherd.  

• Разделение по сегментам помогает отделить бизнес-логику от представления.  

• Изменения в Sherd требуют тщательного код-ревью.  

• Изоляция модулей обеспечивает стабильность фундамента проекта.  

• Переиспользование кода не всегда экономит время.  

• Необходимость архитектурных митингов для рефлексии и улучшения структуры кода.  

• Совместные усилия команды для создания удобного фундамента для потребителей кода.  

• Архитектурные решения представляют собой баланс между изоляцией и переиспользованием кода.  

• Изоляция позволяет независимым изменениям, но может усложнить модификацию элементов.  

• Переиспользование кода повышает уровень абстракции, но создаёт зависимости, которые могут быть нежелательными.  

• Изначально FSD позиционировался как способ переиспользования кода.  

• Со временем акцент сместился на независимость и абстракцию элементов.  

• Концепт «фича» позволяет более качественно декомпозировать код по бизнесу.  

• Сегменты — важная часть FSD, которую часто недооценивают.  

• В сегментах нет строгих правил импорта, что делает их менее структурированными.  

• Разделение на сегменты помогает выделить абстракции без лишних архитектурных границ.  

• «Фичерс фест» позволяет сохранить разделение по бизнесу и избежать лишних архитектурных границ.  

• Этот подход предпочтительнее «пейджис фест» для сложных проектов.  

• «Фичерс фест» требует более глубокого понимания и навыков от команды.  

• Обучение строится вокруг концепций и абстракций.  

• Необходимо чётко называть и объяснять различные подходы к FSD.  

• Абстракции помогают лучше понять и использовать FSD в разных проектах.  

• Создание конкретных сборок FSD может помочь в обучении и применении подхода.  

• Примеры сборок могут включать микрофронтенд FSD и интеграцию с разными фреймворками.  

• Конкретные сборки позволят охватить больше кейсов и улучшить понимание FSD.  

• Приглашение к участию в развитии проекта через телеграм-чат.  

• Возможность получить помощь и поддержку для начала работы над проектом.  

• Совместное развитие проекта способствует его успеху и популяризации.  

• Разделите код по страницам, выделив отдельную папку для страниц.  

• Формализуйте точку входа в структуру предложения.  

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

• Разрабатывайте новые функции в FSD, постепенно мигрируя старые функции.  

• Избегайте создания «идеальной» FSD CICD, которая может отпугнуть разработчиков.  

• Эта стратегия подходит для средних проектов, где миграцию можно провести за обозримое время.  

• Паттерн закрытия слоёв не будет официально продвигаться в FSD.  

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

• Обсуждение паттернов лучше вести в отдельном топике.  

• Многие современные инструменты сложно интегрировать с FSD из-за их архитектуры.  

• Инструменты, не поддерживающие модульность и изоляцию, плохо интегрируются с FSD.  

• Проблемы интеграции часто связаны с архитектурой самих инструментов, а не с FSD.  

• Большие папки страниц могут потребовать реструктуризации.  

• Реструктуризацию лучше проводить на архитектурных митингах, а не в рамках работы над тикетами.  

• Ретроспективный анализ разработки поможет определить, когда нужно разбить большую папку.  

• Обсуждение возможных глобальных изменений в FSD.  

• Подчёркивается важность сотрудничества и избегания конкуренции между различными стандартами.  

• Благодарность участникам за участие в дискуссии.