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

• Ведущий приветствует зрителей и представляет Льва, который занимается развитием фичеслайс версии 2.1.  

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

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

• В проекте сейчас активно участвуют Лев, Антон Медведев и Сергей Сова.  

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

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

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

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

• Лев подчеркивает, что проект остается волонтерским и развивается на энтузиазме.  

• Лев обсуждает, что проект развивается медленно из-за отсутствия монетизации.  

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

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

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

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

• Лев также упоминает улучшения в потоке и другие мелкие изменения.  

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

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

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

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

• FSD предлагает эвристики для разделения на сущности, фичи и виджеты.  

• Эти эвристики часто дают сбой при большом количестве связей.  

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

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

• FSD описывает эвристики, но не гарантирует успех без правильного применения.  

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

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

• Важно, чтобы люди понимали, зачем нужна декомпозиция и как она улучшает код.  

• Многие не понимают, зачем нужен FSD, и не видят в нем пользы.  

• Важно объяснять, какие преимущества FSD дает по сравнению с затратами на внедрение.  

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

• Документация FSD не всегда четко объясняет, как декомпозиция улучшает код.  

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

• Раздел о методологии в документации FSD требует доработки.  

• Кричащая архитектура описывает, что информация о структуре приложения заложена в его структуре.  

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

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

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

• Фсд предоставляет информацию о сущностях, кейсах, виджетах и пейджах.  

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

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

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

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

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

• Информация о сущностях и фичах может быть "грязной".  

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

• Фсд подходит для небольших приложений, но ограничен по масштабируемости.  

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

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

• Фсд приходит к формату с четко определенными доменами.  

• Ограниченные контексты - это слабо связанные технические модули.  

• Пейджис фест и фичерс фест - подходы к организации кода.  

• Фсд должен быть стандартизирован для разных объемов приложений.  

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

• Объем приложения и количество слабо связанных частей - ключевые факторы.  

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

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

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

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

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

• Импорты работают только при наличии сущностей в домене.  

• Разделение на FSD не всегда необходимо для маленьких приложений.  

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

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

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

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

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

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

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

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

• FSD часто модифицируется для адаптации к конкретным проектам.  

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

• Важно, чтобы документация по FSD была организована эффективно.  

• FSD часто используется неэффективно, так как не соответствует конкретным требованиям проекта.  

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

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

• FSD рассматривается как набор архитектурных паттернов и структура проекта.  

• Важно понимать, что FSD является структурой проекта, а не просто набором паттернов.  

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

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

• Цель FSD - кристаллизация архитектурных мыслей в практическую структуру.  

• Важность документации и практических примеров для применения FSD.  

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

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

• Проблемы с обучением людей программированию через FSD.  

• Теория и практика в FSD: абстрактные концепты и конкретные примеры.  

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

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

• Трудности в понимании бизнес-фичей и их декомпозиции.  

• Недостаток четкого формулирования концептов в FSD.  

• Важность теории для понимания и применения на практике.  

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

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

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

• Обсуждение архитектуры на текущем проекте.  

• Проблемы с внедрением FSD в существующие проекты.  

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

• Обсуждение вопроса о Best Practice с авторизацией на Next.js.  

• Упоминание о создании звезды на ковре и пиве.  

• Обсуждение текущей документации и концепции.  

• Вопрос о Feature Base Architecture на фронте.  

• Обсуждение доклада Олега из Зана о Feature Base подходе.  

• Сравнение Feature Base с текущей архитектурой.  

• Feature Base как абстрактная формулировка.  

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

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

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

• Пример с модульной архитектурой.  

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

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

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

• Проблемы с декомпозицией и рефакторингом.  

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

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

• Оптимизация удаляемости кода.  

• Обсуждение переиспользования кода.  

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

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

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

• Важность рефлексии и архитектурных митингов.  

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

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

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

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

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

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

• Фичи позволяют сделать более качественное декомпозицию по бизнесу.  

• Сегменты в FSD важны для разделения абстракций.  

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

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

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

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

• Пейджинг фест может быть проще, но имеет свои ограничения.  

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

• Важно называть и объяснять концепции, чтобы они были понятны.  

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

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

• Важно учитывать разные группы пользователей и их намерения.  

• Конкретные примеры и гайды помогут в обучении и применении FSD.  

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

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

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

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

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

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

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

• Важно, чтобы линтер был установлен и настроен правильно.  

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

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

• Это индивидуальное желание, которое не всем нужно.  

• Важно описать и объяснить, где и как использовать паттерны.  

• Многие современные инструменты плохо интегрируются с FSD.  

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

• Единственный способ справиться с этим — писать гайды и объяснять, как использовать инструменты.  

• Пейджис могут стать толстыми, и это нужно решать на архитектурных митингах.  

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

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