EngineerSpock - IT и программирование

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