Баг был не в Java

Когда что-то идёт не так, первое, что мы обычно делаем как разработчики, — смотрим в свой собственный код. Я поступаю так же. Но есть баги, которые можно перечитывать снова и снова — а ответа в коде так и не найти.

Проблема с подключением к базе данных, неполадка в Docker-образе, забытая переменная окружения, несовпадение кодировок, сетевой таймаут или странный ответ от другого сервиса — всё это может часами маскироваться под обычное Java-исключение. На деле же с самим приложением всё в порядке.

Stack trace показывает не всё

Увидеть исключение — это ещё не значит найти его причину. Stack trace показывает мне, где проблема всплыла на поверхность. А вот докопаться до настоящей первопричины — это уже отдельная задача.

Например, проблема на уровне базы данных вполне может проявиться как исключение на уровне приложения. Сбой в пуле соединений иногда даёт о себе знать только при обращении к репозиторию. А сетевой глюк легко замаскируется под исключение, брошенное FeignClient.

Именно поэтому в последнее время во время отладки я всё реже спрашиваю «где именно возникла эта ошибка?» и всё чаще — «через какие слои системы эта ошибка прошла, прежде чем добраться сюда?»

Отладка — это тоже инженерия

Я не считаю, что хороший разработчик определяется только количеством выпущенных фич. Спокойное, методичное исследование того, что на самом деле происходит в уже работающей системе, — не менее важная часть работы.

Иногда лучшее решение — не писать больше кода. А доказать, где проблемы точно нет.

Больше моих текстов можно найти здесь:
https://aladdinbiyabangerd.site/ru/writing