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

Проблемы

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

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

Примеры:

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

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

Примеры:

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

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

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

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

Примеры:

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

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

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

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

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

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

Страница была полезной?

Ваш фидбек помогает нам улучшать документацию