Перейти к основному содержимому

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

Проблемы

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

Bus-factor & Onboarding

Проект и его архитектуру понимает лишь ограниченный круг людей

Примеры:

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

Неявные и неконтролируемые последствия

Множество неявных сайд-эффектов при разработке/рефакторинге ("все зависит от всего")

Примеры:

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

Неконтролируемое переиспользование логики

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

При этом, обычно есть две крайности:

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

Примеры:

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

Требования

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

note

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

Explicitness

  • Должно быть легко осваивать и объяснять команде проект и его архитектуру
  • Структура должна отображать реальные бизнес-ценности проекта
  • Должны быть явными сайд-эффекты и связи между абстракциями
  • Должно быть легко обнаруживать дублирование логики, не мешая уникальным реализациям
  • Не должно быть распыления логики по всему проекту
  • Не должно быть слишком много разнородных абстракций и правил для хорошей архитектуры

Control

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

Adaptability

  • Хорошая архитектура должна быть применима к большинству проектов
    • С уже существующими инфраструктурными решениями
    • На любой стадии развития
  • Не должно быть зависимости от фреймворка и платформы
  • Должна быть возможность легко масштабировать проект и команду, с возможностью параллелизации разработки
  • Должно быть легко подстраиваться под изменяющиеся требования и обстоятельства

См. также