1889 подписчиков
Компромиссы в программировании: красота, скорость и здравый смысл
Иногда кажется, что тормоза из-за архитектуры приложения. Что DDD — это про красивые диаграммы, а не про реальные задачи. Что вся эта модульность, слои, интерфейсы и DI только замедляют работу.
Я частенько встречал подобное отношение у программистов.
Но правда состоит в том, что в каждом конкретно случае надо разбираться, что именно тормозит.
Был проект, где требовалось быстро и стабильно обработать большой поток данных. Всё вроде делали правильно:
🟠 чистая архитектура
🟠 разнесённые слои: контроллер, сервис, домен, репозиторий
🟠 маппинги, DTO, интерфейсы — полный фарш
Код получался аккуратный, читаемый, поддерживаемый.
Но после релиза бизнес пишет:
— «Что-то тормозит. Секунды 2 отклика на конкретный запрос. Почему?»
Естественная реакция: «Наверное, архитектура перегружена. Надо упростить!»
Но я решил не спешить, а сначала прогнал всё это через профайлер.
Результаты:
✅ основное время уходит в запрос к БД
✅ ORM вёл к ленивым выборкам, вызывающим проблему N+1 (все в курсе что это?)
✅ сериализация — тащим лишние поля
✅ сам проход по всем слоям занимает всего лишь миллисекунды
То есть, архитектура не была причиной тормозов. Просто система была неоптимальна в других местах.
Но при этом был и другой проект, где из-за чрезмерного количества обёрток и абстракций
🟠 каждое изменение в бизнес-логике требовало править 6–8 файлов
🟠 а простой CRUD завязывался на 5 слоёв, хотя этого никто не просил
И вот там уже было не торможение, а "архитектурная перегрузка", которая била по velocity команды.
💡 Компромисс здесь не между «хорошей архитектурой» и «быстрой работой».
Реальный компромисс — между:
✅ чистотой и здравым смыслом
✅ инженерной красотой и разумной простотой
✅ будущим развитием и задачей «сделать на этой неделе»
Если ты автоматически винишь архитектуру в медленной работе — остановись.
Если ты слепо лепишь 8 слоёв, даже когда можно обойтись одним — тоже остановись.
Инженер — это не тот, кто делает "по канону", а тот, кто умеет соотнести абстракцию с реальностью.
#инженерия #архитектура #разработка #программирование #инженерныекомпромиссы
1 минута
22 апреля