Про безопасные миграции написано уже тысячу раз. Мы все наизусть знаем и про expand/contract, и про обратную совместимость, и про то, что схему нельзя ломать под трафиком. А потом всё равно наступаем на эти грабли.

Вот свежий случай. Была задача на полчаса, надо было переименовать две перепутанные колонки. Прод целиком не лёг, но за одну выкатку я собрал сразу два инцидента. Причём один прилетел изнутри сервиса, а второй снаружи, оттуда, откуда я вообще не ждал.

Дальше расскажу, как так вышло

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

После выхода Claude Opus 4.7 стало очевидно, что агент технически быстрее меня. А 28 мая Anthropic выпустила Opus 4.8 с теми же ценами, заметно лучшим coding/agentic-скором и новой возможностью держать в голове миграции на сотни тысяч строк

Знает он, кажется, всё. Все фреймворки, все паттерны, всю историю последних пятнадцати лет на StackOverflow и GitHub. По объёму знаний это легко сеньор, местами принципал

Но при всём этом ему не хватает трёх вещей

Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки

На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте

При разборе продакшн heap dump я обнаружил странность: Hibernate Query Plan Cache занимал почти треть памяти. Обычный IN (:ids) внезапно генерировал тысячи SQL-планов и раздувал heap.

Почему так происходит и как полностью решить проблему с помощью ANY(:ids) — разбираю пошагово на реальном примере

Меня зовут Игорь Симаков, я тимлид Java-разработки в команде Маркетплейс Банки.Ру. Сегодня на практическом примере разберу использование UNIT-тестирования. Оно применяется как для тестирования состояния, так и для проверки поведения кода. В этом материале сосредоточусь на последнем аспекте. Покажу, как использовать JUnit, Mockito и AssertJ для тестирования кода, а также JaCoCo для оценки покрытия тестами на примере простого мини-сервиса.

Эта статья основана на моем внутреннем воркшопе, который я проводил для своих коллег. В моем репозитории на GitHub можно ознакомиться с текстом доклада. Там содержится обзор основных понятий, используемых в статье, а также подробное описание инструментов.