Решить одну проблему и не создать следующую
Как разработчики мы иногда хотим решить проблему слишком быстро.
- Появилось исключение — чиним.
- Производительность слабая — добавляем кэш.
- Сервисы слишком связаны — выделяем новый.
- Запросов к базе много — пишем другой запрос.
Проблема решена. Потом появляется другая.
Фикс — не всегда решение
На реальных проектах я видел это несколько раз. Изменение, которое убирает одну проблему, может создать новое поведение в другом месте.
Кэш снимает нагрузку с базы. Но теперь нужно решить, когда это значение обновляется.
Вынесенный сервис может упростить деплой. Но теперь сетевая проблема — тоже ваша проблема.
Добавленная валидация останавливает неверные данные. Но теперь то же правило нужно применить и во всех других точках входа.
То есть у технического решения есть своя цена.
Сейчас я сначала спрашиваю «почему»
Прежде чем что-то менять, я стараюсь понять проблему настолько, насколько получается.
- Почему это происходит?
- На каком слое проблема?
- На что ещё может повлиять это изменение?
- Есть ли решение проще?
И самый важный вопрос: я действительно решаю проблему или только прячу симптом?
Этот вопрос не даёт написать много лишнего кода.
Простое решение обычно лучше
Хороший backend-код для меня — не тот, в котором больше всего абстракций.
Если проблему можно понятно решить внутри одного сервиса, нет смысла добавлять слой только ради того, чтобы архитектура выглядела «профессиональнее».
Если задачу решает ограничение в базе, держать это правило только в Java-коде никто не обязывает.
А если два модуля меняются вместе, искусственно разносить их — тоже не всегда верное решение.
Со временем я всё чаще вижу, что инженерия — не столько про то, что добавить, сколько про то, чего добавлять не нужно.