В современной production-разработке сложность проекта зачастую играет
второстепенную роль. Мы приносим простоту в жертву ради будущих великих
нагрузок: наши базы данных распределены, а наши сервисы раздроблены на множество
микросервисов.
Такой подход имеет место быть в enterprise среде, но к сожалению он все плотнее
укореняется и в других областях разработки: indie-программирование, разработка в
относительно небольших компаниях и так далее. В этой статье я бы хотел
поговорить именно про архитектурной сложности проекта, а не про нюансы написания
кода.
Скрытая сложность проекта
Казалось бы, всем уже известно что делать просто - хорошо, а делать сложно -
плохо. Но как определить что сложно, а что хорошо?
С архитектурной точки зрения сложность можно определить как количество связанных
друг с другом объектов: чем их больше, тем система более сложная. Предположим мы
решили сделать обычный современный web-сайт. Из чего он состоит:
- frontend - web-интерфейс с которым взаимодействует пользователь
- backend - API сервис к которому обращается frontend для получения данных и
совершения действий - база данных - отвечает за хранение данных сайта
В какой-то момент мы понимаем, что страницы нашего сайта могли бы грузиться
гораздо быстрее, если бы мы на каждое открытие страницы пользователем не делали
запросы к БД. Решение? Конечно же, добавить кеш:
Кажется, ничего сложного, обычный стек, но даже набор компонентов скрывает в
себе много нюансов, увеличивающих сложность работы с проектом.