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