История изменений

если тест сложен для понимания только из-за того что json убрали в ресурсы, то возможно с этим тестом что-то не так

Ну хорошо, для больших json уместно, но если JSON занимает например 15 строк, неужели это повод его вынести в ресурс при наличии мультистрок? На пограничные 15 строк можно натравить статический анализатор на CI, чтоб никто не нарушал этого правила.

погоди. что вообще текстовые sql-запросы делают в яве?

Для orm пишут в аннотациях ql, запросы маленькие, но какая разница? Запросы в яве! Сейчас часто используют ORM потому все уже позабывали как это было раньше с raw sql, куча sql была прямо в java и одним из вариантов было использовать что-то вроде ibatis.

Мультистроки появятся и можно будет все это в жабе оставить. Никакой разницы с sql в xml или отдельных файлах, только экономия времени.

В плане у ломбока, аспектов, спринга и прочих модных слов есть одна общая проблема - огромное количество черной магии. Ты сможешь сходу рассказать как работает изнутри каждая аннотация ломбока? Или как происходит врезка аспектов? Или канонiчный пример - во что развернется чудесная SpringBootApplication?

Преждевременное беспокойство, ну ок, однажды что-то случится и чо? Один день дебага, но каждый день экономия по 15 минут чтения кода. Чем меньше кода не относящегося к бизнес процессам, тем лучше.

Вот честно, я кучу времени трачу на анализ кода, активно пользуюсь букмарками в idea, потоу как одна чать связанна с другой частью, которая в другом файле, а вызвается из третьего файла, после каждого бага у меня по 5-10 букмарков и столько же брейкпоинтов. Чтоб было понятно я не один работаю, в команде с десятью другими девелоперами и баги берутся из пула багов, потому если и встречаешь свой код, то он уже обычно модифицирован кем-то другим. Потому по моим представлениям нужно меньше кода и статические анализаторы на CI. В идеале вообще может язык сменить, на тот где ненужны аннотации, xml и прочие файлы в ресурсах.

если тест сложен для понимания только из-за того что json убрали в ресурсы, то возможно с этим тестом что-то не так

Ну хорошо, для больших json уместно, но если JSON занимает например 15 строк, неужели это повод его вынести в ресурс при наличии мультистрок? На пограничные 15 строк можно натравить статический анализатор на CI, чтоб никто не нарушал этого правила.

погоди. что вообще текстовые sql-запросы делают в яве?

Для orm пишут в аннотациях ql, запросы маленькие, но какая разница? Запросы в яве! Сейчас часто используют ORM потому все уже позабывали как это было раньше с raw sql, куча sql была прямо в java и одним из вариантов было использовать что-то вроде ibatis.

Мультистроки появятся и можно будет все это в жабе оставить. Никакой разницы с sql в xml или отдельных файлах, только экономия времени.

В плане у ломбока, аспектов, спринга и прочих модных слов есть одна общая проблема - огромное количество черной магии. Ты сможешь сходу рассказать как работает изнутри каждая аннотация ломбока? Или как происходит врезка аспектов? Или канонiчный пример - во что развернется чудесная SpringBootApplication?

Преждевременное беспокойство, ну ок, однажды что-то случится и чо? Один день дебага, но каждый день экономия по 15 минут чтения кода. Чем меньше кода не относящегося к бизнес процессам, тем лучше.

Вот честно, я кучу времени трачу на анализ кода, активно пользуюсь букмарками в idea, потоу как одна чать связанна с другой частью, которая в другом файле, а вызвается из тертьего файла, после каждого бага у меня по 5-10 букмаров и столько же брейкпоинтов. Чтоб было понятно я не один работаю, в команде с десятью другими девелоперами и баги берутся из пула багов, потому если и встречаешь свой код, то он уже обычно модифицирован кем-то другим. Потому по моим представлениям нужно меньше кода и статические анализаторы на CI. В идеале вообще может язык сменить, на тот где ненужны аннотации, xml и прочие файлы в ресурсах.