motivation.md

Motivation

Зачем нужна методология, причины создания

---

Главная идея feature-sliced - облегчить и удешевить разработку комплексных и развивающихся проектов, на основании объединения результатов исследований и опыта разного рода широкого круга разработчиков

Многие вопросы, проблемы - разобраны в "О методологии"

Очевидно, что это не будет серебряной пулей, и само собой, у методологии будут свои границы применимости

Тем не менее, возникают резонные вопросы, касаемо целесообразности такой методологии в целом

🔎 Почему не хватает существующих решений?

Речь обычно о таких аргументах:

• "Зачем нужна отдельная новая методология, если уже есть давно зарекомендовавшие себя подходы и принципы проектирования SOLID, KISS, YAGNI, DDD, GRASP, DRY и т.д."
• "Все проблемы проекта решаются хорошей документацией, тестами и выстроенными процессами"
• "Проблем бы и не было - если бы все разработчики следовали всему выше перечисленному"
• "Все придумано уже до вас, вы просто не можете этим пользоваться"
• "Возьмите {FRAMEWORK_NAME} - там решено уже все за вас"

Если отвечать вкратце:

• Только существования принципов недостаточно для проектирования хорошей архитектуры

  Не все их знают до конца, еще меньше правильно понимают и применяют

  Принципы проектирования слишком общие, и не дают конкретного ответа на вопрос "А как спроектировать структуру и архитектуру масштабируемого и гибкого приложения?"

• Документация/Тесты/Процессы - это, конечно, хорошо, но увы, при больших затратах - они не всегда решают поставленных проблем по архитектуре и внедрению новых людей в проект

  • Время входа каждого разработчика в проект не сильно уменьшается, т.к. документация чаще всего выйдет огромной / устаревшей
  • Постоянно следить за тем, что каждый понимает архитектуру одинаково - требует также колоссального количества ресурсов
  • Не забываем и про bus-factor

• Существующие фреймворки (Angular/feature-u/...) - решают большой скоуп проблем, но не везде могут быть применены

  • Имеющиеся решения, как правило, имеют высокий порог входа, из-за чего сложно найти новых разработчиков

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

    (См. вопросы наподобие "У меня в проекте React/Vue/Redux/Effector/Mobx/{YOUR_TECH} - как мне лучше выстроить структуру сущностей и связи между ними?")

  Да, безусловно, готовые решения имеют и свои достоинства, которые мы хотим сохранить и в нашей методологии (например стандартизация проектов, как в Angular)

И по итогу - получаем "уникальные как снежинки" проекты, каждый из которых требует длительного погружения сотрудника, и знания, которые вряд ли будут применимы на другом проекте

Помимо перечисленного, есть и другие проблемы

• Никто не гарантирует, что принятое решение оправдает себя в долгосрочной перспективе

  Т.к. подобные решения (даже если частично) обкатывались только в рамках компании, а также опираются только на опыт самих разработчиков команды

  @sergeysova: "Это ровно та ситуация, которая сейчас есть в нашей сфере frontend разработки: каждый лид напридумает себе различных архитектур и структур проекта, при этом не факт, что эти структуры пройдут проверку временем, в итоге кроме него развивать проект могут максимум два человека и каждого нового разработчика нужно погружать снова."

• Неоткуда взять советов по такой специфичной архитектуре, негде ознакомиться с best-practices, опытом других разработчиков и также в целом найти обсуждения сложных кейсов

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

Более подробно на вопросы ответили в дискуссии

🧑‍💻 Зачем методология разработчикам?

• Методология позволит сконцентрироваться на реализации бизнес-фич, а не на разработке своих велосипедов

  Т.е. мы тем самым решаем проблему стандартизации решений и архитектур проектов

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

• Методология рассчитана на разработчиков, нацеленных на проверенное опытом решение по проектировению комплексной бизнес-логики

  Однако ясно, что методология - это в целом про набор best-practices, статьи от методологии, рассматривающих определенные проблемы и кейсы при разработке

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

🧑‍💼 Зачем методология бизнесу?

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

  Появляются доп. гарантии найти людей на следующие итерации проекта

• С методологией бизнес получит решения для большинства вопросов, возникающих разработке систем

  Поскольку чаще всего бизнес хочет получить фреймворк/решение, которое бы решало львиную долю проблем при развитии проекта

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

  Чаще всего тех.долг копится и копится со временем, и ответственность за его разрешение лежит и на лиде, и на команде

  Методология же позволит заранее предупреждать возможные проблемы при масштабировании и развитии проекта

• Методология может принести пользу проекту как на этапе поддержки и развития проекта, так и на этапе MVP

  Да, на MVP чаще всего важнее "фичи, а не заложенная на будущее архитектура"

  Но даже в условиях ограниченных сроков, зная best-practices из методологии - можно "обойтись малой кровью", при проектировании MVP-версии системы, находя разумный компромисс (нежели лепить фичи "как попало")

  То же самое можно сказать и про тестирование

• Методология подойдет не любому бизнесу

  Наша методология не нужна, если

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

  Если говорить про размеры...

  • Малый бизнес - чаще всего нуждается в готовом и очень быстром решении. Только при росте бизнеса (хотя бы до почти среднего), он понимает - чтобы клиенты продолжали пользоваться, нужно в том числе уделить время качеству и стабильности разрабатываемых решений
  • Средний бизнес - обычно понимает все проблемы разработки, и даже если приходится "устраивать гонку за фичами", они все равно уделяют время на доработки по качеству, рефакторинг и тесты (и само собой - на хорошую архитектуру)
  • Большой бизнес - обычно уже имеет обширную аудиторию, штат сотрудников, и гораздо более обширный набор своих практик, и наверное даже - свой подход к архитектуре, поэтому идея взять чужую - им приходит не так часто

🚀 Планы

Основная часть целей изложена здесь

Но помимо этого, стоит проговорить и наши ожидания от методологии в будущем

• Сейчас мы пытаемся объединить весь наш разнородный опыт core-team, и получить по итогу закаленную опытом методологию

  Конечно, мы можем получить по итогу Angular 3.0., но гораздо важней здесь - исследовать саму проблему проектирования архитектуры сложных систем

  И да - у нас есть претензии и к текущей версии методологии, но мы хотим общими усилиями прийти к единому и оптимальному решению (учитывая, в том числе, и опыт комьюнити)

• Если все сложится хорошо, то методология не будет ограничиваться только спецификацией и тулкитом

  Т.е. при идеальном раскладе

  • возможно будут и доклады, статьи
  • возможно будут CODE_MODEs для миграций на другие технологии проектов, написанных согласно методологии
  • не исключено, что по итогу можем дойти и до мейнтейнеров крупных технологических решений

    Особенно для React, по сравнению с другими фреймворками - это главная проблема, т.к. он не говорит как решать определенные проблемы

    Потому и получаем уникальные и разнородные решения для React-проектов, из-за чего тратятся дополнительные ресурсы на разработку

📑 См. также

• Обсуждение "Методология не нужна?"
• Илья Климов "О проектных знаниях"
• "О методологии: ограничения, цели, проблемы"