#featuresliced_design — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #featuresliced_design, aggregated by home.social.
-
Мой опыт онбординга разраба с амнезией
Давай признаем, ты чуть ли не 90% кода пишешь с помощью клода, кодекса или еще какого агента. Ты выпускаешь несколько мр-ов в день, пушишь несколько тысяч строк кода, и быстро просматриваешь псевдо код на ревью, чтобы доказать самому себе, что это действительно ты напряг мозг и сделал задачу. Ты делаешь ровно то, что и всегда, думая, что агент просто ускоряет цикл разработки, который ты проводил ежедневно. Однако не покидает ощущение, что это какой-то цирк. Ты просто осознанно повторяешь действия, которые раньше имели смысл, но в глубине души фрустрируешь от странности происходящего.
https://habr.com/ru/articles/1066100/
#llm #aiагенты #claudecode #codex #featuresliced_design #vibecoding #frontend #архитектура
-
Мой опыт онбординга разраба с амнезией
Давай признаем, ты чуть ли не 90% кода пишешь с помощью клода, кодекса или еще какого агента. Ты выпускаешь несколько мр-ов в день, пушишь несколько тысяч строк кода, и быстро просматриваешь псевдо код на ревью, чтобы доказать самому себе, что это действительно ты напряг мозг и сделал задачу. Ты делаешь ровно то, что и всегда, думая, что агент просто ускоряет цикл разработки, который ты проводил ежедневно. Однако не покидает ощущение, что это какой-то цирк. Ты просто осознанно повторяешь действия, которые раньше имели смысл, но в глубине души фрустрируешь от странности происходящего.
https://habr.com/ru/articles/1066100/
#llm #aiагенты #claudecode #codex #featuresliced_design #vibecoding #frontend #архитектура
-
Мой опыт онбординга разраба с амнезией
Давай признаем, ты чуть ли не 90% кода пишешь с помощью клода, кодекса или еще какого агента. Ты выпускаешь несколько мр-ов в день, пушишь несколько тысяч строк кода, и быстро просматриваешь псевдо код на ревью, чтобы доказать самому себе, что это действительно ты напряг мозг и сделал задачу. Ты делаешь ровно то, что и всегда, думая, что агент просто ускоряет цикл разработки, который ты проводил ежедневно. Однако не покидает ощущение, что это какой-то цирк. Ты просто осознанно повторяешь действия, которые раньше имели смысл, но в глубине души фрустрируешь от странности происходящего.
https://habr.com/ru/articles/1066100/
#llm #aiагенты #claudecode #codex #featuresliced_design #vibecoding #frontend #архитектура
-
Пятая кнопка за вечер. Архитектура фронтенда под контекст LLM
К концу второго месяца vibe coding на фронте моего пет-проекта жили пять компонентов кнопки, четыре спиннера, компонент страницы на 700 строк и шапка, которая показывала один баланс, пока модалка рядом показывала другой. LLM-агент писал всё это уверенно, быстро и с хорошим стилем кода. Фронтенд под LLM деградирует даже быстрее бэкенда — и тому есть причины: от качества обучающей выборки, где вперемешку лежат три поколения React, до самой природы JSX, где разметка, логика и состояние легально живут в одном файле. Под катом — что в итоге сработало: Feature-Sliced Design, урезанный до трёх слоёв, как карта для агента; dependency-cruiser в роли архитектурного контракта, который нельзя нарушить; кодогенерация API-клиента из OpenAPI вместо доменной модели; за что я простил Tailwind; и честно — про самое слабое место конвейера: агент, который верстает вслепую. Это продолжение статьи про бэкенд, но читается и само по себе.
https://habr.com/ru/articles/1060634/
#llm #aiагенты #claudecode #vibecoding #чистая_архитектура #featuresliced_design #nextjs #dependency_check #tanstack_query #openapi
-
Пятая кнопка за вечер. Архитектура фронтенда под контекст LLM
К концу второго месяца vibe coding на фронте моего пет-проекта жили пять компонентов кнопки, четыре спиннера, компонент страницы на 700 строк и шапка, которая показывала один баланс, пока модалка рядом показывала другой. LLM-агент писал всё это уверенно, быстро и с хорошим стилем кода. Фронтенд под LLM деградирует даже быстрее бэкенда — и тому есть причины: от качества обучающей выборки, где вперемешку лежат три поколения React, до самой природы JSX, где разметка, логика и состояние легально живут в одном файле. Под катом — что в итоге сработало: Feature-Sliced Design, урезанный до трёх слоёв, как карта для агента; dependency-cruiser в роли архитектурного контракта, который нельзя нарушить; кодогенерация API-клиента из OpenAPI вместо доменной модели; за что я простил Tailwind; и честно — про самое слабое место конвейера: агент, который верстает вслепую. Это продолжение статьи про бэкенд, но читается и само по себе.
https://habr.com/ru/articles/1060634/
#llm #aiагенты #claudecode #vibecoding #чистая_архитектура #featuresliced_design #nextjs #dependency_check #tanstack_query #openapi
-
Пятая кнопка за вечер. Архитектура фронтенда под контекст LLM
К концу второго месяца vibe coding на фронте моего пет-проекта жили пять компонентов кнопки, четыре спиннера, компонент страницы на 700 строк и шапка, которая показывала один баланс, пока модалка рядом показывала другой. LLM-агент писал всё это уверенно, быстро и с хорошим стилем кода. Фронтенд под LLM деградирует даже быстрее бэкенда — и тому есть причины: от качества обучающей выборки, где вперемешку лежат три поколения React, до самой природы JSX, где разметка, логика и состояние легально живут в одном файле. Под катом — что в итоге сработало: Feature-Sliced Design, урезанный до трёх слоёв, как карта для агента; dependency-cruiser в роли архитектурного контракта, который нельзя нарушить; кодогенерация API-клиента из OpenAPI вместо доменной модели; за что я простил Tailwind; и честно — про самое слабое место конвейера: агент, который верстает вслепую. Это продолжение статьи про бэкенд, но читается и само по себе.
https://habr.com/ru/articles/1060634/
#llm #aiагенты #claudecode #vibecoding #чистая_архитектура #featuresliced_design #nextjs #dependency_check #tanstack_query #openapi
-
FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями
Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.
https://habr.com/ru/articles/1060256/
#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг
-
FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями
Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.
https://habr.com/ru/articles/1060256/
#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг
-
FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями
Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.
https://habr.com/ru/articles/1060256/
#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг
-
Мы увязли в Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья —продолжение предыдущей: Мой справочник по Feature-Sliced Design . На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.
https://habr.com/ru/companies/T1Holding/articles/1028836/
#react #reactjs #vue #vuejs #javascript #typescript #featuresliced_design #fsd #frontend #вебразработка
-
Мы увязли в Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья —продолжение предыдущей: Мой справочник по Feature-Sliced Design . На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.
https://habr.com/ru/companies/T1Holding/articles/1028836/
#react #reactjs #vue #vuejs #javascript #typescript #featuresliced_design #fsd #frontend #вебразработка
-
Мы увязли в Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья —продолжение предыдущей: Мой справочник по Feature-Sliced Design . На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.
https://habr.com/ru/companies/T1Holding/articles/1028836/
#react #reactjs #vue #vuejs #javascript #typescript #featuresliced_design #fsd #frontend #вебразработка
-
Мой справочник по Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии. В этой статье я продолжаю использовать те же принципы и часть терминологии, что и в предыдущей . Здесь я, в основном, описываю структурирование по правилам методологии. А в следующей статье, напротив, рассмотрю, как можно улучшить структуру проекта, намеренно нарушая правила FSD. Заранее предупрежу, что правила методологии носят рекомендательный, а не обязательный характер. Их назначение — задать направление структурирования, а дальше принимать решения нужно в зависимости от конкретного проекта и ситуации в нём. Строгое же следование правилам может привести к бо̒льшим проблем, чем их нарушение. Если заметите ошибки — пишите в комментариях!
https://habr.com/ru/companies/T1Holding/articles/976220/
#react #javascript #typescript #featuresliced_design #fsd #vue #vuejs #vuejs #reactjs
-
Мой справочник по Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии. В этой статье я продолжаю использовать те же принципы и часть терминологии, что и в предыдущей . Здесь я, в основном, описываю структурирование по правилам методологии. А в следующей статье, напротив, рассмотрю, как можно улучшить структуру проекта, намеренно нарушая правила FSD. Заранее предупрежу, что правила методологии носят рекомендательный, а не обязательный характер. Их назначение — задать направление структурирования, а дальше принимать решения нужно в зависимости от конкретного проекта и ситуации в нём. Строгое же следование правилам может привести к бо̒льшим проблем, чем их нарушение. Если заметите ошибки — пишите в комментариях!
https://habr.com/ru/companies/T1Holding/articles/976220/
#react #javascript #typescript #featuresliced_design #fsd #vue #vuejs #vuejs #reactjs
-
Мой справочник по Feature-Sliced Design
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии. В этой статье я продолжаю использовать те же принципы и часть терминологии, что и в предыдущей . Здесь я, в основном, описываю структурирование по правилам методологии. А в следующей статье, напротив, рассмотрю, как можно улучшить структуру проекта, намеренно нарушая правила FSD. Заранее предупрежу, что правила методологии носят рекомендательный, а не обязательный характер. Их назначение — задать направление структурирования, а дальше принимать решения нужно в зависимости от конкретного проекта и ситуации в нём. Строгое же следование правилам может привести к бо̒льшим проблем, чем их нарушение. Если заметите ошибки — пишите в комментариях!
https://habr.com/ru/companies/T1Holding/articles/976220/
#react #javascript #typescript #featuresliced_design #fsd #vue #vuejs #vuejs #reactjs
-
Clean Architecture во frontend: почему я ушёл от FSD
Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался. Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
https://habr.com/ru/articles/938894/
#clean_architecture #frontend #fsd #featuresliced_design #react #vue
-
Clean Architecture во frontend: почему я ушёл от FSD
Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался. Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
https://habr.com/ru/articles/938894/
#clean_architecture #frontend #fsd #featuresliced_design #react #vue
-
Clean Architecture во frontend: почему я ушёл от FSD
Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался. Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
https://habr.com/ru/articles/938894/
#clean_architecture #frontend #fsd #featuresliced_design #react #vue
-
FSD Forge: Как я создал небольшую CLI для Feature-Sliced Design и почему это было нужно
Привет, Хабр! Меня зовут Виктор, я программирую на TypeScript/Java и это моя первая статья, в которой я хочу поделиться историей создания fsd-forge — CLI-инструмента для упрощения работы с архитектурой Feature-Sliced Design (FSD) в проектах на React и TypeScript. В этой статье я расскажу, почему решил создать этот инструмент, как он устроен, какие проблемы решает, и какие уроки я вынес из процесса разработки. Что такое Feature-Sliced Design и зачем нужен CLI? Feature-Sliced Design — это архитектурный подход для структурирования фронтенд-приложений, который помогает организовать код в масштабируемых проектах. FSD делит приложение на слои ( app , pages , features , widgets , entities , shared ), делая код модульным, читаемым и легким для поддержки. Однако создание новой структуры FSD или добавление сущностей (например, страниц или виджетов) вручную занимает время и чревато ошибками, особенно в больших командах. Идея fsd-forge родилась из личной потребности. Работая над несколькими React-проектами, параллельно переписывая с Angular на React еще один, я заметил, что:
-
FSD Forge: Как я создал небольшую CLI для Feature-Sliced Design и почему это было нужно
Привет, Хабр! Меня зовут Виктор, я программирую на TypeScript/Java и это моя первая статья, в которой я хочу поделиться историей создания fsd-forge — CLI-инструмента для упрощения работы с архитектурой Feature-Sliced Design (FSD) в проектах на React и TypeScript. В этой статье я расскажу, почему решил создать этот инструмент, как он устроен, какие проблемы решает, и какие уроки я вынес из процесса разработки. Что такое Feature-Sliced Design и зачем нужен CLI? Feature-Sliced Design — это архитектурный подход для структурирования фронтенд-приложений, который помогает организовать код в масштабируемых проектах. FSD делит приложение на слои ( app , pages , features , widgets , entities , shared ), делая код модульным, читаемым и легким для поддержки. Однако создание новой структуры FSD или добавление сущностей (например, страниц или виджетов) вручную занимает время и чревато ошибками, особенно в больших командах. Идея fsd-forge родилась из личной потребности. Работая над несколькими React-проектами, параллельно переписывая с Angular на React еще один, я заметил, что:
-
FSD Forge: Как я создал небольшую CLI для Feature-Sliced Design и почему это было нужно
Привет, Хабр! Меня зовут Виктор, я программирую на TypeScript/Java и это моя первая статья, в которой я хочу поделиться историей создания fsd-forge — CLI-инструмента для упрощения работы с архитектурой Feature-Sliced Design (FSD) в проектах на React и TypeScript. В этой статье я расскажу, почему решил создать этот инструмент, как он устроен, какие проблемы решает, и какие уроки я вынес из процесса разработки. Что такое Feature-Sliced Design и зачем нужен CLI? Feature-Sliced Design — это архитектурный подход для структурирования фронтенд-приложений, который помогает организовать код в масштабируемых проектах. FSD делит приложение на слои ( app , pages , features , widgets , entities , shared ), делая код модульным, читаемым и легким для поддержки. Однако создание новой структуры FSD или добавление сущностей (например, страниц или виджетов) вручную занимает время и чревато ошибками, особенно в больших командах. Идея fsd-forge родилась из личной потребности. Работая над несколькими React-проектами, параллельно переписывая с Angular на React еще один, я заметил, что:
-
Призываю переименовать Layers в Feature-Sliced Design методологии
В статье я сначала коротко объясню, как лично я понимаю и использую FSD, для тех, кто не знаком с ней, или знаком, но хочет сравнить с чужим видением. Однако, пишу я это в основном для того, чтобы обратить ваше внимание, что названия Layers подобраны не по алфавиту, и лично мне это мешает. Подумайте, может и вам мешает. На мой взгляд, их стоит переименовать в алфавитном порядке, даже жертвуя смыслом, чтобы они лучше отображались в файловой структуре проекта.
-
Призываю переименовать Layers в Feature-Sliced Design методологии
В статье я сначала коротко объясню, как лично я понимаю и использую FSD, для тех, кто не знаком с ней, или знаком, но хочет сравнить с чужим видением. Однако, пишу я это в основном для того, чтобы обратить ваше внимание, что названия Layers подобраны не по алфавиту, и лично мне это мешает. Подумайте, может и вам мешает. На мой взгляд, их стоит переименовать в алфавитном порядке, даже жертвуя смыслом, чтобы они лучше отображались в файловой структуре проекта.
-
Призываю переименовать Layers в Feature-Sliced Design методологии
В статье я сначала коротко объясню, как лично я понимаю и использую FSD, для тех, кто не знаком с ней, или знаком, но хочет сравнить с чужим видением. Однако, пишу я это в основном для того, чтобы обратить ваше внимание, что названия Layers подобраны не по алфавиту, и лично мне это мешает. Подумайте, может и вам мешает. На мой взгляд, их стоит переименовать в алфавитном порядке, даже жертвуя смыслом, чтобы они лучше отображались в файловой структуре проекта.
-
Feature-Sliced Design (FSD): Основы и практические примеры архитектуры
Когда я только начинал свою карьеру фронтенд-разработчика, часто сталкивался с проблемами поддержки кода в проектах. Со временем я понял, что структура кода имеет решающее значение. Так я узнал о Feature-Sliced Design . Этот подход помогает разбивать проект на функциональные части, что упрощает работу с кодом и его сопровождение. Давайте разберемся как это работает.
-
Feature-Sliced Design (FSD): Основы и практические примеры архитектуры
Когда я только начинал свою карьеру фронтенд-разработчика, часто сталкивался с проблемами поддержки кода в проектах. Со временем я понял, что структура кода имеет решающее значение. Так я узнал о Feature-Sliced Design . Этот подход помогает разбивать проект на функциональные части, что упрощает работу с кодом и его сопровождение. Давайте разберемся как это работает.
-
Feature-Sliced Design (FSD): Основы и практические примеры архитектуры
Когда я только начинал свою карьеру фронтенд-разработчика, часто сталкивался с проблемами поддержки кода в проектах. Со временем я понял, что структура кода имеет решающее значение. Так я узнал о Feature-Sliced Design . Этот подход помогает разбивать проект на функциональные части, что упрощает работу с кодом и его сопровождение. Давайте разберемся как это работает.