yooteam 24 мая 2021 в 13:33

Как оптимизировать повседневные backend-задачи: три видео с митапа по Java

20 мая прошел наш седьмой митап для Java-разработчиков ЮMoney Jam. Смотрите видео от наших докладчиков, которые делятся кейсами:

Как добавлять в чистовой код на Java тестовое поведение и спать спокойно.
Как обеспечить отказоустойчивость к высоким нагрузкам внутри кластера базы данных.
Как не попасть в Jar Hell.

Владимир Плизга, backend-разработчик ЦФТ. Инъекция тестовых поведений: как выйти сухим из воды?

Ситуации, требующие правок кода не для production.
Что выбрать: штатные средства, аспектно-ориентированный подход или всё вместе.
Как внедрять в приложение почти любое тестовое и отладочное поведение, не запачкав репозиторий грязными хаками и не пересобирая приложение.

Григорий Скобелев, программист отдела разработки серверных решений ЮMoney. Зашардируем это!

Что делать, когда кластер БД трещит от нагрузки, и как грамотно масштабировать данные.
Как построить отказоустойчивый кластер баз данных, который будет справляться с высокой нагрузкой.
Как обеспечить отказоустойчивость внутри кластера БД с помощью шардирования данных на нашем примере.

Вита Комарова, старший программист отдела разработки серверных решений ЮMoney. Как не попасть в Jar Hell

Что такое Jar Hell и к чему он может привести.
Как мы боремся с Jar Hell в проектах ЮMoney.
Инструменты, которые помогают избежать Jar Hell.

Задавайте вопросы по докладам в комментариях, и наши эксперты вам ответят. А чтобы не пропустить следующие митапы, подпишитесь на наш Telegram-канал.

Теги:

Хабы:

Комментарии 6

AlexeyOs 25 мая 2021 в 12:14
0
Ну некрасиво yooteam поступает. Написала вопросы и ссылки на ролики в ютуб вставила в качестве ответа. И в роликах даже таймкодов нету. Так ладно бы сами пользователи в комментариях таймкоды бы сделали, так нет, комментарии отключили.
- yooteam 25 мая 2021 в 12:31
  +1
  Здравствуйте! Таймкоды во всех видео с митапа добавили вчера, обновили описание роликов сразу после публикации видео. Вопросы спикерам по теме выступлений вы можете задать здесь, в комментариях на Хабре.
AlexeyOs 27 мая 2021 в 14:36
+1
Вопросы по инъекции тестовых поведений:
1) Придумали же контейнеры для бинов, которые можно подменять mock объектами с тестовыми поведением, а тут зачем-то прям методы заменяем и называем это Side Effect Injection, не кажется что велосипед изобретаем?

2) Если запускать в режиме Debug как быстро стартуют те инструменты, что вы сравнивали?
- Toparvion 28 мая 2021 в 05:09
  0
  AlexeyOs, привет!
  1) Иногда кажется)) Но от идеи не отказываемся, потому что:
  - Работа с бинами — это специфика IoC, которого может не быть в приложении вовсе (и это не всегда значит, что приложение плохое, а разработчики — бракоделы)
  - Даже если всё-таки закладываться на наличие IoC-контейнера, то какого? Только лишь Spring? А может, Guice? А вдруг там CDI? Поддерживать каждый — такое себе решение. Гораздо целесообразнее не наступать себе на горло и не зависеть от этой переменной составляющей.
  - И потом, а где тогда хранить mock-бины? В src/test/java не пойдёт, потому что модифицированное поведение нам нужно не в тестах, а в обычном режиме работы приложения. Класть к основным исходникам, конечно, можно, но это возвращает нас к обычному подходу "If'ы+настройки", а значит, эти тестовые поделки снова уедут на production и защита от их случайного срабатывания снова ляжет на совесть людей, а не на формальный механизм выкашивания лишнего. Впрочем, буду честен, пару раз, в особо ~~накуренных~~ нетривиальных случаях мы сами так делали, но только подключение тестового бина обеспечивали не настройкой, а дроплетом, т.е. в отсутствие модицификации тестовый бин вообще никак не попадал в IoC-контейнер и даже не загружался как класс в JVM. Это пример комбинации подходов, о которой я говорил в конце доклада. Другой пример см. на этих слайдах другой версии доклада.
  2) Для AspectJ и Byteman специальных тестов по этой части не делал, разве что чисто визуально кажется, что AspectJ стартует чуть медленнее. Что касается jMint, то у нас в тестовом окружении большинство приложений по умолчанию стартуют одновременно и с отладчиком (в режиме suspend=n, разумеется), и с Java-агентом jMint, но на времени старта это не сказывается. С точки зрения подкапотной механики, отладчик не привносит здесь ничего нового, поэтому и не вызывает задержек. Единственная особенность — в порядке подключения агентов (ведь отладчик — тоже агент, только "нативный"). Если в команде запуска JVM указать агентов не в том порядке, то отладчик не сможет ходить по исполняемому коду jMint (впрочем, вряд ли этого кого-то волнует).
  - aleksandy 2 июня 2021 в 12:05
    
    0
    Работа с бинами — это специфика IoC
    
    Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
    
    И потом, а где тогда хранить mock-бины? В src/test/java не пойдёт, потому что модифицированное поведение нам нужно не в тестах, а в обычном режиме работы приложения.
    
    Именно в src/test/… и хранить, если мы говорим про тесты. А вот для чего нужно модифицированное поведение не в тестах, я слабо себе представляю. Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
    - Toparvion 2 июня 2021 в 18:55
      
      0
      
      Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
      Дело как раз в том, что далеко не всегда задача сводится к тестированию одного бина; нередко возникает потребность модификации сквозных поведений или функционала, не обёрнутого в бины. Больше того, применение Side Effect Injection отнюдь не сводится к одному лишь тестированию. Слово "тестовый" в названии доклада означает, в первую очередь, принадлежность к тестовому (не production) окружению. Например, когда нужно временно поменять что-то в библиотечном коде или на определенном этапе отключить проверки безопасности.
      
      Именно в src/test/… и хранить, если мы говорим про тесты
      Если бы речь была только о тестах, то, безусловно, да, так и нужно было бы сделать. Но как я говорил в докладе и повторился чуть выше здесь, это далеко не всегда так.
      
      Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
      Да, полностью, и да, можно (хоть и не обязательно) выделять в отдельный артефакт, так как SEI — это не разновидность тестов, а альтернативный подход к troubleshooting'у и воспроизведению сложных тестовых кейсов. Его можно использовать как в составе интеграционных тестов, так и самостоятельно.

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

Как оптимизировать повседневные backend-задачи: три видео с митапа по Java

Владимир Плизга, backend-разработчик ЦФТ. Инъекция тестовых поведений: как выйти сухим из воды?

Григорий Скобелев, программист отдела разработки серверных решений ЮMoney. Зашардируем это!

Вита Комарова, старший программист отдела разработки серверных решений ЮMoney. Как не попасть в Jar Hell

Похожие публикации

Информация

Дата основания

Локация

Сайт

Численность

Дата регистрации

Представитель

Виджет

Ссылки

Блог на Хабре

Самое читаемое

Ваш аккаунт

Разделы

Информация

Услуги