У нас неплохие навыки в фронтенде, анализе, бэкенде, однако до хакатона с ml мы ни разу не работали :)
Согласна, команда уже сплоченная, распределение ролей прошло быстро + есть умение быстро изучать информацию, что безумно помогло нам?
Что вызывало опасения, так это организация работы, так как поздно приступили к кейсу, чуть не пропустили некоторые дедлайны, лишились двух участников в начале?
Спасибо за ваше мнение. Приятно, что, возможно, мы подготовлены к таким мероприятиям чуть лучше, чем думаем )
Мы тоже столкнулись с этой проблемой, поэтому немного модифицировали исходную архитектуру - мы добавили папки sub-entities и sub-features в папки сущностей и фич соотвественно.
Например, у нас есть entity company со своими модельками, одна из которых включает модель talkStep. TalkStep является отдельной сущностью, но существует только в рамках сущности company, поэтому в папке company, кроме стандартных папок апи, моделей и подобного, есть папка sub-entities с сущностью talkStep, что позволяет в компании использовать тип talkStep.
К сожалению, примеров с сущностями, которые имеют один тип вложенности и при этом пересекаются, у нас в проекте нет, возможно, в вашем случае какие-то типы являются подтипами
Я согласна с вами, что FSD можно трансформировать под свои нужды, ведь архитектура проекта - дело командное, как понятнее всем, так и делаем.
У нас в проекте FSD значительно улучшил переиспользование компонентов, так как многие фичи используется хотя бы в двух местах. Безусловно, есть фичи, которые лежат для одного конкретного компонента, зато вся логика и апи вынесены из общего компонента. Иногда, когда дробление не имеет смысла (есть гарантия, что компонент ну точно будет использоваться только в рамках верхнеуровневого), мы оставляем его в папке родителя, но выносим в подпапку, стараясь дать каждому компоненту одно назначение.
Для меня и моей команды FSD показался логичным и аккуратным, хотя немного модифицировать пришлось :) Но архитектура - это дело вкуса, поэтому благодарю за обратное мнение ?
Я добавлю уточнение по поводу переиспользования фичей и дробления, чтобы польза от FSD в моем проекте была немного очевиднее ?
У нас неплохие навыки в фронтенде, анализе, бэкенде, однако до хакатона с ml мы ни разу не работали :)
Согласна, команда уже сплоченная, распределение ролей прошло быстро + есть умение быстро изучать информацию, что безумно помогло нам?
Что вызывало опасения, так это организация работы, так как поздно приступили к кейсу, чуть не пропустили некоторые дедлайны, лишились двух участников в начале?
Спасибо за ваше мнение. Приятно, что, возможно, мы подготовлены к таким мероприятиям чуть лучше, чем думаем )
Мы тоже столкнулись с этой проблемой, поэтому немного модифицировали исходную архитектуру - мы добавили папки sub-entities и sub-features в папки сущностей и фич соотвественно.
Например, у нас есть entity company со своими модельками, одна из которых включает модель talkStep. TalkStep является отдельной сущностью, но существует только в рамках сущности company, поэтому в папке company, кроме стандартных папок апи, моделей и подобного, есть папка sub-entities с сущностью talkStep, что позволяет в компании использовать тип talkStep.
К сожалению, примеров с сущностями, которые имеют один тип вложенности и при этом пересекаются, у нас в проекте нет, возможно, в вашем случае какие-то типы являются подтипами
Благодарю за ваш опыт!
Я согласна с вами, что FSD можно трансформировать под свои нужды, ведь архитектура проекта - дело командное, как понятнее всем, так и делаем.
У нас в проекте FSD значительно улучшил переиспользование компонентов, так как многие фичи используется хотя бы в двух местах. Безусловно, есть фичи, которые лежат для одного конкретного компонента, зато вся логика и апи вынесены из общего компонента. Иногда, когда дробление не имеет смысла (есть гарантия, что компонент ну точно будет использоваться только в рамках верхнеуровневого), мы оставляем его в папке родителя, но выносим в подпапку, стараясь дать каждому компоненту одно назначение.
Для меня и моей команды FSD показался логичным и аккуратным, хотя немного модифицировать пришлось :) Но архитектура - это дело вкуса, поэтому благодарю за обратное мнение ?
Я добавлю уточнение по поводу переиспользования фичей и дробления, чтобы польза от FSD в моем проекте была немного очевиднее ?