architecture.md

Об архитектуре

Общие мысли о том, что мы считаем хорошей архитектурой

---

⚠️ Проблемы

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

• Проект и его архитектуру понимает только один человек

  Чаще всего - изначальный автор

  См. также

  • "Сложно добавить человека в разработку"
  • "На каждую проблему - у каждого свое мнение как обходить" (позавидуем ангуляру)
  • "Не понимаю что происходит в этом большом куске монолита"
  • и т.д.

• Тьма-тьмущая неявных сайд-эффектов при разработке/рефакторинге

  Т.е. "все зависит от всего"

  См. также

  • "Фича импортит фичу"
  • "Я обновил(а) стор одной страницы, а отвалился функционал на другой"
  • "Логика размазана по всему приложению, и невозможно отследить - где начало, где конец"
  • и т.д.

• Сложно переиспользовать/модифицировать логику

  Либо большая папка components, либо для каждого случая пишет все с нуля - без shared-модулей

  См. также

  • "У меня в проекте есть n-реализаций одной и той же бизнес-логики, за что приходится ежедневно расплачиваться"
  • "В проекте есть 6 разных компонентов кнопки/попапа/..."
  • "Свалка хелперов"
  • и т.д.

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

• 🧔 "Обычно чем меньше команда, тем лучше работает"
• 👧 "Идея [изолированных фич] хорошая, но работает полностью - редко"
• 🧑 "Не всякий бизнес готов вкладываться в качество и архитектуру, кому-то просто нужны фичи. Т.е. сделал - и забыл"
• 👴 "Разработчики сами редко понимают важность архитектуры"
• 👩 "Если нельзя хорошо написать, хочется хотя бы легко удалить/отрефакторить полностью какую-то часть"
• 👱‍♂️ "У меня все зависит от всего - но я не знаю как сделать лучше"

---

📋 Требования

Потому, кажется логичным предъявить наши хотелки желаемые требования к этой мифической и прекрасной архитектуре:

Примечание: Везде где говорится "легко", подразумевается скорее "относительно легко для широкого круга разработчиков", т.к. ясно, что не получится сделать идеального решения для абсолютно всех

explicit Понятность/Явность

• easy-understand Легко понимать, вникать и объяснять команде

  Чтобы понимали не только "избранные"

  А потому нужно четко выявить абстракции и расположить их на нужном уровне, в зависимости от назначения

• discoverability Должно быть легко осваивать проект благодаря методологии

  Опять же - чтобы проект понимал не один человек, но и другие

  Чтобы не было проблем найти людей, кто сможет "подхватить" разработку этого проекта

• business-goals Структура должна отображать реальные бизнес-ценности проекта
• side-effects Все сайд-эффекты и связи между абстракциями - должны быть явными

  Не должна у нас фича где-то на нижнем уровне импортить стор другой

• duplicates Явное обнаружение дублирования, с возможными уникальными реализациями под каждую функциональность

  Т.е. возможность обнаружить слишком сильное дублирование логики и одновременно - позволять писать самостоятельную логику для каждой фичи

  Даже если где-то есть похожие/немного повторяющиеся моменты

• no-scattering Логика не должна распыляться по проекту

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

• no-redundant Должно быть минимум абстракций, для применения методологии

  Т.е. у нас не должно быть 3 типа моделей, 2 типа фичей и т.д.

control Контроль/Изолированность

• boost-benefits Архитектура должна ускорять решение задач / внедрение фич
• work-parallelisation Параллелизация работы команды над проектом
• project-dev Возможность контролировать разработку проекта
• code-mutations Просто расширять/модифицировать/удалять код
• decoupling Декомпозиция & Изолированность функционала и абстракций
• disposability Возможность удалить/тотально отрефакторить некоторые части отдельно от других позднее

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

  Т.е. любая абстракция (feature/entity/...) должна быть спроектирована, как "одноразовая"

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

adaptability Адаптивность/Кастомизируемость

• infrastructure-agnostic Подход помогает выстроить подходящую проекту архитектуру
• easy-integration Легко внедрять в проекты с уже имеющейся архитектурой

  Чтобы даже при базовой адаптации проектов по нашей методологии - чувствовался профит

• versatility Применимость для разных проектов

  Не везде, например, нужны "процессы" - поэтому нужны в том числе и опциональные абстракции и решения

• tech-independent Независимость от фреймворка и платформы
• scalability Легко масштабируется при развитии проекта

  Логика проекта не уменьшается со временем, как и не уменьшается команда разработки

• flexibility Легко подстраивается под изменяющиеся требования проекта

  Обычно проект относительно легко строится на первых итерациях. Но большинство примеров архитектур не выдерживают изменение требований / функциональности - т.к. изначально рассчитаны под "изначальный слепок ожиданий"

---

❔ FAQ

Возможно, будет позже вынесено в общий FAQ файл

Структура === Архитектура?

Архитектура - про абстракции и выстроение связей между ними (shared/features/pages/...)

Но без надлежащей структуры - хорошей архитектуры не сделать

Нужна ли мне методология только для "понимания и ясности" что происходит в проекте?

Скорее да, чем нет

Иначе приходится читать огромные директории components/...

Нужна ли архитектура/методология начинающему?

Обычно, когда проектируешь разрабатываешь проект в одно лицо - все идет гладко

Но если появляются паузы в разработке, добавляются новые разработчики в команду - тогда-то и наступают проблемы