Мотивация
Главная идея Feature-Sliced Design - облегчить и удешевить разработку комплексных и развивающихся проектов, на основании объединения результатов исследований, обсуждения опыта разного рода широкого круга разработчиков.
Очевидно, что это не будет серебряной пулей, и само собой, у методологии будут свои границы применимости.
Тем не менее, возникают резонные вопросы, касаемо целесообразности такой методологии в целом
Более подробно обсудили в дискуссии
Почему не хватает существующих решений?
Речь обычно о таких аргументах:
- "Зачем нужна отдельная новая методология, если уже есть давно зарекомендовавшие себя подходы и принципы проектирования
SOLID
,KISS
,YAGNI
,DDD
,GRASP
,DRY
и т.д."- "Все проблемы проекта решаются хорошей документацией, тестами и выстроенными процессами"
- "Проблем бы и не было - если бы все разработчики следовали всему выше перечисленному"
- "Все придумано уже до вас, вы просто не можете этим пользоваться"
- "Возьмите {FRAMEWORK_NAME} - там решено уже все за вас"
Одних принципов недостаточно
Только существования принципов недостаточно для проектирования хорошей архитектуры
Не все их знают до конца, еще меньше правильно понимают и применяют
Принципы проектирования слишком об щие, и не дают конкретного ответа на вопрос: "А как спроектировать структуру и архитектуру масштабируемого и гибкого приложения?"
Процессы не всегда работают
Документация/Тесты/Процессы - это, конечно, хорошо, но увы, даже при больших затратах на них - они не всегда решают поставленных проблем по архитектуре и внедрению новых людей в проект
- Время входа каждого разработчика в проект не сильно уменьшается, т.к. документация чаще всего выйдет огромной / устаревшей
- Постоянно следить за тем, что каждый понимает архитектуру одинаково - требует также колоссального количества ресурсов
- Не забываем и про bus-factor
Существующие фреймворки не везде могут быть применены
- Имеющиеся решения, как правило, имеют высокий порог входа, из-за че го сложно найти новых разработчиков
- Также, чаще всего, выбор технологии уже определен до наступления серьезных проблем в проекте, а потому нужно уметь "работать с тем что есть" - не привязываясь к технологии
Q: "У меня в проекте
React/Vue/Redux/Effector/Mobx/{YOUR_TECH}
- как мне лучше выстроить структуру сущностей и связи между ними?"
По итогу
Получаем "уникальные как снежинки" проекты, каждый из которых требует длительного погружения сотрудника, и знания, которые вряд ли будут применимы на другом проекте
@sergeysova: "Это ровно та ситуация, которая сейчас есть в нашей сфере frontend разработки: каждый лид напридумает себе различных архитектур и структур проекта, при этом не факт, что эти структуры пройдут проверку временем, в итоге кроме него развивать проект могут максимум два человека и каждого нового разработчика нужно погружать снова."
Заче м методология разработчикам?
Концентрация на бизнес-фичах, а не на проблемах архитектуры
Методология позволяет экономить ресурсы на проектировании масштабируемой и гибкой архитектуры, вместо этого направляя внимание разработчиков на разработку основной функциональности. При этом стандартизируются и сами архитектурные решения из проекта в проект.
Отдельный вопрос, что методология должна заслужить доверие комьюнити, чтобы другой разработчик мог в имеющиеся у него сроки ознакомиться и положиться на нее при решении проблем своего проекта
Проверенное опытом решение
Методология рассчитана на разработчиков, нацеленных на пр оверенное опытом решение по проектированию комплексной бизнес-логики
Однако ясно, что методология - это в целом про набор best-practices, статьи, рассматривающие определенные проблемы и кейсы при разработке. Поэтому - польза от методологии будет и для остального круга разработчиков - кто так или иначе сталкивается с проблемами при разработке и проектировании
Здоровье проекта
Методология позволит заблаговременно решать и отслеживать проблемы проекта, не требуя огромного количества ресурсов
Чаще всего тех.долг копится и копится со временем, и ответственность за его разрешение лежит и на лиде, и на команде
Методология же позволит заранее предупреждать возможные проблемы при масштабировании и развитии проекта
Зачем методология бизнесу?
Быстрый onboarding
С методологией можно нанять человека в проект, который уже предварительно знаком с таким подходом, а не обучать заново
Люди начинают быстрее вникать и приносить пользу проекту, а также появляются дополнительные гарантии найти людей на следующие итерации проекта
Проверенное опытом решение
С методологией бизнес получит решение для большинства вопросов, возникающих при разработке систем
Поскольку чаще всего бизнес хочет получить фреймворк/решение, которое бы решало львиную долю проблем при развитии проекта
Применимость для разных стадий проекта
Методология может принести пользу проекту