Всем привет!
Хочу вернуться к теме "правильных" модульных тестов и подчеркнуть пару важных моментов.
1) должен быть быстрый набор тестов, который можно запускать после каждого изменения в коде. Почему это важно: после небольшого изменения в коде всегда понятна причина падения. После нескольких изменений подряд - уже сложнее. Быстрый - понятие нечеткое, но пойдем от обратного - 10 минут точно не быстро) 5 - тоже многовато IMHO. Идеально - минута, две.
2) как я уже писал - тесты должны быть антихрупкими. Хрупкие тесты с течением времени приводят к такому же результату, как и их отсутствие. Тесты часто падают, их отключают или не запускают, рефакторинг делать страшно, код объявляется legacy и переписывается.
Как этого можно добиться:
- не писать тесты на код, который постоянно меняется. Это один из возможных вариантов, не панацея!) Если это не бизнес-логика - это допустимо. В этом случае модульные тесты можно заменить на интеграционные, проверящие более высокоуровневый результат, которые реже меняется.
- не проверять в тесте детали реализации, тестировать результат, который потребитель тестируемого метода ожидает от него. Хорошая статья на эту тему - https://habr.com/ru/company/jugru/blog/571126/ Тестируя только результат мы теряем точность теста, но увеличиваем антихрупкость. Это необходимый компромис. Исключение: сложные утилитные методы, где алгоритм - порядок вызовов - важен.
3) покрытие кода тестами - не панацея. С одной стороны покрытие 30-50% - плохо, т.к. показывает, что много кода не покрыто тестами. С другой стороны покрытие 100% не говорит, что код хороший. Почему:
- не добавляяя Assert, добавив E2E тесты и закрыв их в try catch можно достичь очень хороших результатов по покрытию)
- важно различать Line Coverage и Condition (Branch) coverage. Первое считает процент покрытых срок, второе - процент протестированных путей, по которым можно прийти от начала к концу метода. В случае SonarQube тут все хорошо - он считает свою метрику, которая совмещает обе https://docs.sonarqube.org/latest/user-guide/metric-definitions/ В теории если покрыты все условия, то и по строчкам кода должно быть 100%. Или в проекте есть код, который не используется. В общем метрике SonarQube можно верить)
- предположим мы написали на первый взгляд полноценный набор тестов, с Assert-ми, все как положено. Покрытие 100% по новому коду. Но есть метод с побочным эффектом - он не только возвращает результат, но и сохраняет его внутри класса для отчетности или сравнения в будущих вызовах. Если этого не знать \ забыть - получим неполноценный тест. Конечно, есть Single Responsibility, неожиданные побочные эффекты это плохо, при TDD забыть про только что написанный код сложно, но в других случаях ситация может быть на практике. Другой кейс - тестируемый метод может вызывать библиотечную функцию, внутренности который мы не знаем. Соответственно, все возможные комбинации параметров для нее тоже не знаем. Не факт, что все такие комбинации нужно тестировать в конретном тесте - мы же не тестируем внешние библиотеки. Но факт, что какие-то важные кейсы для нашего бизнес-процесса можно упустить.
4) принцип Single Responsibility для теста звучит так: тест отвечает за одну бизнес-операцию, единицу поведения. Соотношение 1 тестовый класс = 1 тестируемый объект - не правило. Соответственно, в названии тестового класса не обязательно привязываться к названию тестируемого класса, тем более, что его в будущем могут отрефакторить.
5) ну и финальный момент - серебрянной пули нет, перед написанием тестов надо думать, что и как тестировать и выбирать наилучщий вариант.
P.S. Также хочу посоветовать хорошую книгу про тесты от автора статьи из 2) - https://habr.com/ru/company/piter/blog/528872/
#unittests #books
Хочу вернуться к теме "правильных" модульных тестов и подчеркнуть пару важных моментов.
1) должен быть быстрый набор тестов, который можно запускать после каждого изменения в коде. Почему это важно: после небольшого изменения в коде всегда понятна причина падения. После нескольких изменений подряд - уже сложнее. Быстрый - понятие нечеткое, но пойдем от обратного - 10 минут точно не быстро) 5 - тоже многовато IMHO. Идеально - минута, две.
2) как я уже писал - тесты должны быть антихрупкими. Хрупкие тесты с течением времени приводят к такому же результату, как и их отсутствие. Тесты часто падают, их отключают или не запускают, рефакторинг делать страшно, код объявляется legacy и переписывается.
Как этого можно добиться:
- не писать тесты на код, который постоянно меняется. Это один из возможных вариантов, не панацея!) Если это не бизнес-логика - это допустимо. В этом случае модульные тесты можно заменить на интеграционные, проверящие более высокоуровневый результат, которые реже меняется.
- не проверять в тесте детали реализации, тестировать результат, который потребитель тестируемого метода ожидает от него. Хорошая статья на эту тему - https://habr.com/ru/company/jugru/blog/571126/ Тестируя только результат мы теряем точность теста, но увеличиваем антихрупкость. Это необходимый компромис. Исключение: сложные утилитные методы, где алгоритм - порядок вызовов - важен.
3) покрытие кода тестами - не панацея. С одной стороны покрытие 30-50% - плохо, т.к. показывает, что много кода не покрыто тестами. С другой стороны покрытие 100% не говорит, что код хороший. Почему:
- не добавляяя Assert, добавив E2E тесты и закрыв их в try catch можно достичь очень хороших результатов по покрытию)
- важно различать Line Coverage и Condition (Branch) coverage. Первое считает процент покрытых срок, второе - процент протестированных путей, по которым можно прийти от начала к концу метода. В случае SonarQube тут все хорошо - он считает свою метрику, которая совмещает обе https://docs.sonarqube.org/latest/user-guide/metric-definitions/ В теории если покрыты все условия, то и по строчкам кода должно быть 100%. Или в проекте есть код, который не используется. В общем метрике SonarQube можно верить)
- предположим мы написали на первый взгляд полноценный набор тестов, с Assert-ми, все как положено. Покрытие 100% по новому коду. Но есть метод с побочным эффектом - он не только возвращает результат, но и сохраняет его внутри класса для отчетности или сравнения в будущих вызовах. Если этого не знать \ забыть - получим неполноценный тест. Конечно, есть Single Responsibility, неожиданные побочные эффекты это плохо, при TDD забыть про только что написанный код сложно, но в других случаях ситация может быть на практике. Другой кейс - тестируемый метод может вызывать библиотечную функцию, внутренности который мы не знаем. Соответственно, все возможные комбинации параметров для нее тоже не знаем. Не факт, что все такие комбинации нужно тестировать в конретном тесте - мы же не тестируем внешние библиотеки. Но факт, что какие-то важные кейсы для нашего бизнес-процесса можно упустить.
4) принцип Single Responsibility для теста звучит так: тест отвечает за одну бизнес-операцию, единицу поведения. Соотношение 1 тестовый класс = 1 тестируемый объект - не правило. Соответственно, в названии тестового класса не обязательно привязываться к названию тестируемого класса, тем более, что его в будущем могут отрефакторить.
5) ну и финальный момент - серебрянной пули нет, перед написанием тестов надо думать, что и как тестировать и выбирать наилучщий вариант.
P.S. Также хочу посоветовать хорошую книгу про тесты от автора статьи из 2) - https://habr.com/ru/company/piter/blog/528872/
#unittests #books
Хабр
Школы юнит-тестирования
Существуют две основные школы юнит-тестирования: классическая (ее также называют школой Детройта, или Чикаго) и лондонская (ее также называют мокистской школой, от слова mock). Эти школы кардинально...
Всем привет!
Наткнулся недавно на статью в двух частях о Java stacktrace.
Рекомендую!
Из статьи можно узнать:
1) насколько "дороже" возврат из метода через исключения по сравнению с return. Спойлер - сильно дороже
2) как можно съэкономить при создании Exception
3) Как зависит "стоимость" исключения от глубины вызовов. Спойлерить не буду, чтобы не быть кэпом)
4) Плюсы нового API для разбора исключения java.lang.StackWalker. Это Java 9
5) Сколько вызовов влезет в стек при стандартных размерах стека. Спойлер - it depends
Пример стектрейса для затравки: https://mattwarren.org/images/2016/12/Huge%20Java%20Stack%20Trace.png
6) Все возможные методы получения stacktrace у работающего и зависшего процесса. Спойлер - их много) Можно даже из консоли Windows\Linux
7) Немного о том, как работают профилировщики
8) И наконец как взломать JVM и украсть пароли из полей класса
https://habr.com/ru/company/jugru/blog/324932/
https://habr.com/ru/company/jugru/blog/325064/
#java #debug
Наткнулся недавно на статью в двух частях о Java stacktrace.
Рекомендую!
Из статьи можно узнать:
1) насколько "дороже" возврат из метода через исключения по сравнению с return. Спойлер - сильно дороже
2) как можно съэкономить при создании Exception
3) Как зависит "стоимость" исключения от глубины вызовов. Спойлерить не буду, чтобы не быть кэпом)
4) Плюсы нового API для разбора исключения java.lang.StackWalker. Это Java 9
5) Сколько вызовов влезет в стек при стандартных размерах стека. Спойлер - it depends
Пример стектрейса для затравки: https://mattwarren.org/images/2016/12/Huge%20Java%20Stack%20Trace.png
6) Все возможные методы получения stacktrace у работающего и зависшего процесса. Спойлер - их много) Можно даже из консоли Windows\Linux
7) Немного о том, как работают профилировщики
8) И наконец как взломать JVM и украсть пароли из полей класса
https://habr.com/ru/company/jugru/blog/324932/
https://habr.com/ru/company/jugru/blog/325064/
#java #debug
Хабр
Всё, что вы хотели знать о стек-трейсах и хип-дампах. Часть 1
Практика показала, что хардкорные расшифровки с наших докладов хорошо заходят, так что мы решили продолжать. Сегодня у нас в меню смесь из подходов к поиску и анализу ошибок и крэшей, приправленная...
Всем привет!
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Bandlem
Git Tip of the Week: Git Notes - AlBlue’s Blog
Git Tip of the Week: Git Notes
Gtotw
2011
Git
Th...
Gtotw
2011
Git
Th...
Всем привет!
Снова про алгоритмы.
Представим ситуацию, когда для каждого нашего объекта нужно получить адрес, где его хранить. Это может быть сервер в случае шардированной БД или корзина в HashMap. Хорошим решением является функция, которая однозначно по уникальному идентификатору нашей сущности выдаёт адрес сервера. Альтернативой является хранение таблицы соответствия отдельно, в случае распределённой системы это будет отдельный микросервис, что означает +1 запрос и увеличение задержек. Тривиальной реализацией является простой алгоритм - остаток от деления на число серверов. Но у такого есть минус - при изменении числа серверов распределение объектов по серверам или корзинам сильно меняется. Мы же хотим равномерное распределение. Если перестроение HashMap в памяти обычно (!) не проблема, то в случае десятка серверов в сети - ещё какая проблема. Для решения этой проблемы есть алгоритм консистентного хэширования. Он не защищает от перераспределения данных, но фиксирует их размер.
https://jaidayo.livejournal.com/2645.html #algorithm #distributedsystem
P.S. HashMap данный алгоритм не использует, на размерах порядка 1 млн записей рекомендуется сразу задавать начальный размер равный предполагаемому умноженному на 1.5
P.P.S. Хозяйке на заметку: в nginx, при использовании его в качестве балансировщика включить консистентное вычисление хэша от URL запроса можно одной строкой hash $request_uri consistent
P...S А вот документация по использованию алгоритма в Openstack https://docs.openstack.org/swift/latest/ring_background.html
#algorithm
Снова про алгоритмы.
Представим ситуацию, когда для каждого нашего объекта нужно получить адрес, где его хранить. Это может быть сервер в случае шардированной БД или корзина в HashMap. Хорошим решением является функция, которая однозначно по уникальному идентификатору нашей сущности выдаёт адрес сервера. Альтернативой является хранение таблицы соответствия отдельно, в случае распределённой системы это будет отдельный микросервис, что означает +1 запрос и увеличение задержек. Тривиальной реализацией является простой алгоритм - остаток от деления на число серверов. Но у такого есть минус - при изменении числа серверов распределение объектов по серверам или корзинам сильно меняется. Мы же хотим равномерное распределение. Если перестроение HashMap в памяти обычно (!) не проблема, то в случае десятка серверов в сети - ещё какая проблема. Для решения этой проблемы есть алгоритм консистентного хэширования. Он не защищает от перераспределения данных, но фиксирует их размер.
https://jaidayo.livejournal.com/2645.html #algorithm #distributedsystem
P.S. HashMap данный алгоритм не использует, на размерах порядка 1 млн записей рекомендуется сразу задавать начальный размер равный предполагаемому умноженному на 1.5
P.P.S. Хозяйке на заметку: в nginx, при использовании его в качестве балансировщика включить консистентное вычисление хэша от URL запроса можно одной строкой hash $request_uri consistent
P...S А вот документация по использованию алгоритма в Openstack https://docs.openstack.org/swift/latest/ring_background.html
#algorithm
Livejournal
Консистентные хэши (Consistent hashing)
View more presentations from Anton. Download here. Зачем? Есть большой пласт технологий для создания распределенных систем: создание железных решений, распределенного ПО для управления системой, распределенных хранилищь, etc. Все это двигает grid технологии…
Всем привет. Немного про цену создания объектов в Java. Для короткоживущих объектов на последних версиях JVM выигрыш от переиспользования объектов про сравнению с созданием составляет пример 25%. Справедливости ради на Java 8 разница была в 40%, т.е garbage collection развивается. Описание эксперимента тут http://blog.vanillajava.blog/2022/09/java-is-very-fast-if-you-dont-create.html #java #performance
blog.vanillajava.blog
Java is Very Fast, If You Don’t Create Many Objects
You still have to watch how many objects you create. This article looks at a benchmark passing events over TCP/IP at 4 billion events per ...
С другой стороны Java = объекты. Сборщики мусора стали достаточно умными, чтобы запускаться только тогда, когда памяти не хватает, и достаточно быстро убирать короткоживущихе объекты. Можно выбрать сборщик мусора либо с минимальными паузами, либо с минимальным overhead по ресурсам. Про выбор можно почитать тут https://www.baeldung.com/java-choosing-gc-algorithm Перераспределение памяти по ходу работы программы и роста heap можно убрать установив одинаковые xms и xmx, тогда JRE заберёт эту память из системы «навсегда» при старте приложения. Если на сервере много памяти и вы уверены, что heap-а точно хватит на все время работы программы - есть фейковый GC, который имеет ровно одну фичу - падать когда память кончается) https://openjdk.org/jeps/318 Когда это все не работает - примерно на десятках миллионах RPS как в статье из примера выше) #java #gc #performance
Всем привет! Уже упоминал книгу Идеальная работа Роберта Мартина https://habr.com/ru/company/piter/blog/679378/ Дочитал до конца и вот более полный отзыв. Вначале о хорошем: главы про применение TDD на практических задачах с livecoding - must read. Хороша глава про принцип YAGNI - you aren't gonna need it, особенно про то, как скорость современных компьютеров сделала этот принцип более актуальным. Хорошо написано про структуру presentation layer для упрощения тестирования этого слоя. Шаблоны тестирования там же. Хорошо про вязкость процесса программирования - скорость сборки и прогона тестов. Интересные данные про влияние парного программирования на скорость разработки. Только из-за этого книгу могу рекомендовать к прочтению. Но есть на мой взгляд и минус. Сквозь всю книгу проходит тезис про ответственность программиста за код. Вообще говоря мысль правильная. За любую работу нужно отвечать и делать ее качественно. Смущают три момента. 1) пафос, с которым это подаётся. Сразу вспоминается «Даешь пятилетку за четыре года». Или такой персонаж как Тони Робинсон. Делай хорошо, не делай плохо. Да, все тезисы обоснованы, но я бы добавил больше юмора, практических примеров и меньше пафоса. 2) ко многим вещам ты приходишь с опытом. Поэтому требовать одинаково с сеньора и джуна нельзя. Автор про это говорит, один раз, и все. Для кого тогда эти главы? 3) для доказательства хороших идей подтасовки не нужны. Пример с программистами из Volkswagen, которые обманули программу измерения выхлопов, выглядит именно подтасовкой. Вкратце - чтобы пройти новый экологический стандарт для дизельных двигателей руководство компании дало указание разработчикам так настроить программу работы двигателя, чтобы в тестовом режиме все было ок, хотя по факту он выделял больше вредных веществ, чем разрешено. Но штука в том, что с внедрением этого стандарта старые машины продолжают ездить по улицам. И писать что из-за плохих программистов машины причиняют вред здоровью людей... ну такое. Но, повторюсь - читайте главы про TDD, простоту кода, тестирования БД и UI, парное программирование и настройку проекта. #books #tdd
Хабр
Идеальная работа. Программирование без прикрас
Привет, Хаброжители! В книге «Идеальная работа. Программирование без прикрас» легендарный Роберт Мартин (Дядюшка Боб) создал исчерпывающее руководство по хорошей работе для каждого программиста....
Всем привет! Ещё одно ревью на книгу, которую упоминал: Владимир Хориков Принципы юнит-тестирования. https://habr.com/ru/company/piter/blog/528872/ Можно сказать уникальная книга про то, как писать юнит тесты. Я знаю таких всего две - эту и Шаблоны тестирования XUnit. Must read. Некоторые моменты можно обсуждать, но откровенных косяков или воды не нашёл. Что запомнилось.
1) разделение кода на четыре группы: бизнес-логика, контролёр в широком смысле этого слова как код, обрабатывающий входящие запросы, тривиальный код и переусложненный код, в котором есть и внешние зависимости и бизнес-логика. От последнего нужно избавляться через рефакторинг, сводя его к бизнес-логике или контроллерам. На бизнес-логику пишем модульные тесты, на контроллеры - интеграционные. На тривиальный код ничего не пишем)
2) не нужно писать отдельные тесты на каждой класс бизнес-логики, нужно тестировать процессы и стремиться к максимальному покрытию. Для бизнес-логики
3) использование минимум mock в модульных тестах, в идеальном случае их вообще не должно быть. Т.е идея в том, что классы бизнес-логики получают и возвращают DTO, которые можно создать в тесте без всяких mock
4) в случае интеграционных тестов mock нужно делать на неконтролируемые нами внешние зависимости, типа очередей, внешних АС, email транспорта. БД в случае если это не наша частная БД. Если же у нас микросервис со своей БД, которая обновляется вместе с приложением и внешние клиенты в нее не ходят - ее mock-ать не нужно, более того и заменять ее HBase тоже не нужно, т.к иначе мы не сможем полноценно оттестировать работу с БД, да и возникнут накладные расходы на поддержание двух версий скрипов. Это как раз то, где можно дискутировать, но милая мне нравится.
5) чем меньше в приложении слоёв, тем лучше, проще тестировать
6) логирование может являться контрактом, например по требованию сопровождения или если на его основе работает мониторинг, тогда его тоже нужно mock-ать и тестировать.
7) организовать отправку событий, например, логирования, сообщений в Kafka или SMTP можно через стандартизацию механизма событий в доменной модели и обработку событий в слое «контроллеров».
8) если вернутся к модели тестов AAA - Arrange, Act, Assert, то Arrange и Assert в одном тесте может быть много, а вот Act должен быть один, иначе у нас проблемы с нашим Java API. Исключение - интеграционные тесты где сложно поднять контекст.
9) методы с инициализацией тестов типа @Before плохи тем, что сложно читать текст, т.к часть Assert в другом методе. Поэтому лучше использовать отдельные говорящие private/protected методы с параметрами, чтобы можно было настроить тестовые данные под каждый тест
10) название тестового метода должно читаться как фраза, разделять можно подчёркиваниями в случае Java, фраза не обязательно должна быть шаблонной как в BDD, краткость более важна. Кстати, в Kotlin слова в названии теста можно разделять пробелами.
11) интеграционные тесты дают хорошее покрытие, за счёт этого увеличивают защиту от ошибок в коде. Поэтому их лучше всего писать на позитивные сценарии, покрывающие максимум кода и те негативные сценарии, которые не удалось покрыть юнит тестами
12) антихрупкость тестов, о которой я уже писал, становится особенно важна по мере развития проекта. Т.е после некоторого времени более важно, чтобы тесты были антихрупкими, чем чтобы они находили все потенциальные ошибки. Т.к для последнего есть QA и приёмочные тесты
Я перечислил лишь то, что запомнилось, интересным идеей в книге намного больше. Интересных и практических. Повторюсь - must read!
#books #unittests
1) разделение кода на четыре группы: бизнес-логика, контролёр в широком смысле этого слова как код, обрабатывающий входящие запросы, тривиальный код и переусложненный код, в котором есть и внешние зависимости и бизнес-логика. От последнего нужно избавляться через рефакторинг, сводя его к бизнес-логике или контроллерам. На бизнес-логику пишем модульные тесты, на контроллеры - интеграционные. На тривиальный код ничего не пишем)
2) не нужно писать отдельные тесты на каждой класс бизнес-логики, нужно тестировать процессы и стремиться к максимальному покрытию. Для бизнес-логики
3) использование минимум mock в модульных тестах, в идеальном случае их вообще не должно быть. Т.е идея в том, что классы бизнес-логики получают и возвращают DTO, которые можно создать в тесте без всяких mock
4) в случае интеграционных тестов mock нужно делать на неконтролируемые нами внешние зависимости, типа очередей, внешних АС, email транспорта. БД в случае если это не наша частная БД. Если же у нас микросервис со своей БД, которая обновляется вместе с приложением и внешние клиенты в нее не ходят - ее mock-ать не нужно, более того и заменять ее HBase тоже не нужно, т.к иначе мы не сможем полноценно оттестировать работу с БД, да и возникнут накладные расходы на поддержание двух версий скрипов. Это как раз то, где можно дискутировать, но милая мне нравится.
5) чем меньше в приложении слоёв, тем лучше, проще тестировать
6) логирование может являться контрактом, например по требованию сопровождения или если на его основе работает мониторинг, тогда его тоже нужно mock-ать и тестировать.
7) организовать отправку событий, например, логирования, сообщений в Kafka или SMTP можно через стандартизацию механизма событий в доменной модели и обработку событий в слое «контроллеров».
8) если вернутся к модели тестов AAA - Arrange, Act, Assert, то Arrange и Assert в одном тесте может быть много, а вот Act должен быть один, иначе у нас проблемы с нашим Java API. Исключение - интеграционные тесты где сложно поднять контекст.
9) методы с инициализацией тестов типа @Before плохи тем, что сложно читать текст, т.к часть Assert в другом методе. Поэтому лучше использовать отдельные говорящие private/protected методы с параметрами, чтобы можно было настроить тестовые данные под каждый тест
10) название тестового метода должно читаться как фраза, разделять можно подчёркиваниями в случае Java, фраза не обязательно должна быть шаблонной как в BDD, краткость более важна. Кстати, в Kotlin слова в названии теста можно разделять пробелами.
11) интеграционные тесты дают хорошее покрытие, за счёт этого увеличивают защиту от ошибок в коде. Поэтому их лучше всего писать на позитивные сценарии, покрывающие максимум кода и те негативные сценарии, которые не удалось покрыть юнит тестами
12) антихрупкость тестов, о которой я уже писал, становится особенно важна по мере развития проекта. Т.е после некоторого времени более важно, чтобы тесты были антихрупкими, чем чтобы они находили все потенциальные ошибки. Т.к для последнего есть QA и приёмочные тесты
Я перечислил лишь то, что запомнилось, интересным идеей в книге намного больше. Интересных и практических. Повторюсь - must read!
#books #unittests
Хабр
Книга «Принципы юнит-тестирования»
Привет, Хаброжители! Юнит-тестирование — это процесс проверки отдельных модулей программы на корректность работы. Правильный подход к тестированию позволит макс...
Всем привет!
Не JUnit-ом единым...
Если говорить о фреймворках для unit тестирования все наверняка вспомнят JUnit и Mockito. Но есть ещё много чего полезного в этой области. Сегодня расскажу про библиотеки для улучшения читаемости проверок - assert. Про важность читаемости кода, в т.ч тестового я уже писал.
Пример для затравки из AssertJ
assertThat(testList).hasSize(2) .containsExactly("index3", "index4") .isUnmodifiable();
Больше примеров см по ссылкам в конце поста.
Библиотек три.
1) Hamcrest. Старичок, родоначальник жанра, уже не развивается, не рекомендуется к использованию
2) AssertJ - в отличие от hamcrest построен на принципе method chaining, что позволяет использовать автопополнение IDE и выглядит более читаемо. Выводит более понятное сообщение об ошибке, что тоже важно. Есть фича Soft Assertion, позволяющая лениво описать n проверок и выполнить их за раз.
3) Truth - очень похож по принципу работы - method chaining - на AssertJ, при этом менее известен. В качестве преимущества его разработчики указывают более компактное API и более понятное логирование ошибок.
Как AssertJ, так и Truth позволяют создавать свои проверки.
За деталями предлагаю пойти сюда:
https://dzone.com/articles/hamcrest-vs-assertj-assertion-frameworks-which-one
https://habr.com/ru/post/675778/
https://truth.dev/comparison.html
#unittests #rare_test_libs
Не JUnit-ом единым...
Если говорить о фреймворках для unit тестирования все наверняка вспомнят JUnit и Mockito. Но есть ещё много чего полезного в этой области. Сегодня расскажу про библиотеки для улучшения читаемости проверок - assert. Про важность читаемости кода, в т.ч тестового я уже писал.
Пример для затравки из AssertJ
assertThat(testList).hasSize(2) .containsExactly("index3", "index4") .isUnmodifiable();
Больше примеров см по ссылкам в конце поста.
Библиотек три.
1) Hamcrest. Старичок, родоначальник жанра, уже не развивается, не рекомендуется к использованию
2) AssertJ - в отличие от hamcrest построен на принципе method chaining, что позволяет использовать автопополнение IDE и выглядит более читаемо. Выводит более понятное сообщение об ошибке, что тоже важно. Есть фича Soft Assertion, позволяющая лениво описать n проверок и выполнить их за раз.
3) Truth - очень похож по принципу работы - method chaining - на AssertJ, при этом менее известен. В качестве преимущества его разработчики указывают более компактное API и более понятное логирование ошибок.
Как AssertJ, так и Truth позволяют создавать свои проверки.
За деталями предлагаю пойти сюда:
https://dzone.com/articles/hamcrest-vs-assertj-assertion-frameworks-which-one
https://habr.com/ru/post/675778/
https://truth.dev/comparison.html
#unittests #rare_test_libs
DZone
Hamcrest vs. AssertJ
Let's compare two popular open Java assertion frameworks, Hamcrest and AssertJ, for testing RESTful APIs. Check out their features, syntax, and other perks.
Всем привет!
Давно хотел написать про паттерны/шаблоны программирования. Основной вопрос, возникающий при разговоре про паттерны - какая от них польза? Ведь главное - умеет человек кодить или нет.
С одной стороны паттерны - это лишь часть арсенала программиста. Можно заучить все паттерны, но не научиться кодить.
И тут возникает второй вопрос - о каких паттернах мы говорим?
1) самые известные - паттерны проектирования из книги «банды четырёх» https://refactoring.guru/ru/design-patterns/catalog
Это синглтон, фабричный метод, билдер и все все все
2) паттерны Enterprise архитектуры от Фаулера https://martinfowler.com/eaaCatalog/
3) паттерны рефакторинга https://refactoring.com/catalog/ Про них также говорится в книге Идеальная работа Мартина
4) паттерны модульных тестов http://xunitpatterns.com/ и снова в книге Идеальная работа
5) паттерны интеграции корпоративных приложений https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html многие из которых можно встретить в стандарте JMS
6) паттерны микросервисных приложений https://microservices.io/patterns/index.html
7) даже у Kubernates есть паттерны https://www.redhat.com/cms/managed-files/cm-oreilly-kubernetes-patterns-ebook-f19824-201910-en.pdf
8) не говоря уже про антипаттерны https://javarush.ru/groups/posts/2622-chto-takoe-antipatternih-razbiraem-primerih-chastjh-1
9) 10) ...
Из этого списка можно сделать вывод, что паттерны могут быть везде. А из этого второй вывод: паттерны - это удобный способ описания какой-то области разработки. Собственно это и есть их ценность. Шаблоны помогают изучить новую технологию, читать статьи, книги и главное читать код и тесты. Ну и проектировать систему, обсуждать ее архитектуру с коллегами. По сути паттерны - это язык проектирования. А идеальный способ их использования - когда они уже реализованы в неком фреймворке: Singleton и MVC в Spring, Builder в Lombok, Sidecar в k8s, или в языке как Singleton и Decorator в Kotlin.
#patterns #refactoring #unittests
Давно хотел написать про паттерны/шаблоны программирования. Основной вопрос, возникающий при разговоре про паттерны - какая от них польза? Ведь главное - умеет человек кодить или нет.
С одной стороны паттерны - это лишь часть арсенала программиста. Можно заучить все паттерны, но не научиться кодить.
И тут возникает второй вопрос - о каких паттернах мы говорим?
1) самые известные - паттерны проектирования из книги «банды четырёх» https://refactoring.guru/ru/design-patterns/catalog
Это синглтон, фабричный метод, билдер и все все все
2) паттерны Enterprise архитектуры от Фаулера https://martinfowler.com/eaaCatalog/
3) паттерны рефакторинга https://refactoring.com/catalog/ Про них также говорится в книге Идеальная работа Мартина
4) паттерны модульных тестов http://xunitpatterns.com/ и снова в книге Идеальная работа
5) паттерны интеграции корпоративных приложений https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html многие из которых можно встретить в стандарте JMS
6) паттерны микросервисных приложений https://microservices.io/patterns/index.html
7) даже у Kubernates есть паттерны https://www.redhat.com/cms/managed-files/cm-oreilly-kubernetes-patterns-ebook-f19824-201910-en.pdf
8) не говоря уже про антипаттерны https://javarush.ru/groups/posts/2622-chto-takoe-antipatternih-razbiraem-primerih-chastjh-1
9) 10) ...
Из этого списка можно сделать вывод, что паттерны могут быть везде. А из этого второй вывод: паттерны - это удобный способ описания какой-то области разработки. Собственно это и есть их ценность. Шаблоны помогают изучить новую технологию, читать статьи, книги и главное читать код и тесты. Ну и проектировать систему, обсуждать ее архитектуру с коллегами. По сути паттерны - это язык проектирования. А идеальный способ их использования - когда они уже реализованы в неком фреймворке: Singleton и MVC в Spring, Builder в Lombok, Sidecar в k8s, или в языке как Singleton и Decorator в Kotlin.
#patterns #refactoring #unittests
refactoring.guru
Каталог паттернов проектирования
Список паттернов проектирования, сгруппированый по предназанчению, сложности и популярности паттернов. В каталог включены объектно ориентированные паттерны, а также некоторые архитектурные паттерны.
Всем привет!
Сегодня рассмотрим циклические зависимости. Начнем с уровня классов и дойдем до слоев приложения.
1) классы. Технически Java компилятор умеет компилировать взаимозависимые классы за счет того, что является многопроходным - https://ru.wikipedia.org/wiki/Многопроходный_компилятор
Какие могут быть проблемы?
Главная - ухудшается читаемость кода. Да, я снова про нее) Вначале мы читаем метод класса А, затем переходим в зависимый класс Б, потом снова в А - в общем логику кода понять сложно. И это я привел достаточно простой пример.
Соответственно такой код сложнее рефакторить, в примере выше изменение public Java API класса А или Б приведет к изменению и второго класса.
Еще минус - невозможно использовать Dependency Injection через конструктор, а это наиболее естественный путь.
2) пакеты и модули. Проблема с вынесением общего кода. Если пакет\модуль содержит какую-то общую логику и при этом ни от чего не зависит - вынести и переиспользовать его в других проектах элементарно.
К тому же если за направлением зависимостей не следить - со временем общая логика начнет зависеть от прикладной и возникнет цикл. Об том, что это плохо говорит буква D из SOLID - абстракция не должна зависеть от деталей.
3) слои приложения. Число слоев может быть разным. В гексагональной архитектуре их по сути два - бизнес-логика и слой сервисов: веб-контроллеры, доступ к БД, вызовы внешних сервисов... https://lumpov.blogspot.com/2021/01/hexagonal-architecture.html В MVC - view, controller и model. Еще распространен такой вариант - presentation, services, model, storage. Но если образуется цикл, то вся система рушится как карточный домик. Слои имеют смысл, когда можно проследить направление запросов и зависимостей. А цель их применения: разделение бизнес-логики и инфраструктурного кода, что дает возможность достаточно легко сменить\добавить storage или внешнее API. Плюс слои по разному тестируются.
#arch #solid
Сегодня рассмотрим циклические зависимости. Начнем с уровня классов и дойдем до слоев приложения.
1) классы. Технически Java компилятор умеет компилировать взаимозависимые классы за счет того, что является многопроходным - https://ru.wikipedia.org/wiki/Многопроходный_компилятор
Какие могут быть проблемы?
Главная - ухудшается читаемость кода. Да, я снова про нее) Вначале мы читаем метод класса А, затем переходим в зависимый класс Б, потом снова в А - в общем логику кода понять сложно. И это я привел достаточно простой пример.
Соответственно такой код сложнее рефакторить, в примере выше изменение public Java API класса А или Б приведет к изменению и второго класса.
Еще минус - невозможно использовать Dependency Injection через конструктор, а это наиболее естественный путь.
2) пакеты и модули. Проблема с вынесением общего кода. Если пакет\модуль содержит какую-то общую логику и при этом ни от чего не зависит - вынести и переиспользовать его в других проектах элементарно.
К тому же если за направлением зависимостей не следить - со временем общая логика начнет зависеть от прикладной и возникнет цикл. Об том, что это плохо говорит буква D из SOLID - абстракция не должна зависеть от деталей.
3) слои приложения. Число слоев может быть разным. В гексагональной архитектуре их по сути два - бизнес-логика и слой сервисов: веб-контроллеры, доступ к БД, вызовы внешних сервисов... https://lumpov.blogspot.com/2021/01/hexagonal-architecture.html В MVC - view, controller и model. Еще распространен такой вариант - presentation, services, model, storage. Но если образуется цикл, то вся система рушится как карточный домик. Слои имеют смысл, когда можно проследить направление запросов и зависимостей. А цель их применения: разделение бизнес-логики и инфраструктурного кода, что дает возможность достаточно легко сменить\добавить storage или внешнее API. Плюс слои по разному тестируются.
#arch #solid
Wikipedia
Многопроходный компилятор
Многопроходный компилятор (англ. Multi-pass compiler) — тип компилятора, который обрабатывает исходный код или абстрактное синтаксическое дерево программы несколько раз (в отличие от однопроходного компилятора, который проходит программу только один раз).…
Всем привет!
Сегодня расскажу про такую штуку, как rate limiters.
Как следует из названия это компонент для ограничения числа запросов в интервал времени.
Может возникнуть вопрос - причем здесь Java? Да, обычно такие штуки разворачивают на инфраструктуре - например, в k8s или nginx.
Если так можно сделать - так и нужно делать)
Когда так сделать не получится:
1) алгоритм ограничения числа запросов нестандартный, поэтому нужна Java, чтобы его запрограммировать)
2) нужна возможность продвинутого мониторинга числа пропущенных и отбитых запросов
3) при изменении параметров rate limiting нужна умная ребалансировка. Т.е. нельзя просто сбросить счетчики в ноль, т.к. это приведет к падению сервиса, который защищает rate limiter.
4) ну и наконец нет подходящей инфраструктуры
Второй вопрос - в каких кейсах это может понадобиться:
1) не уронить стоящий за вами сервис
2) приоритизировать какие-то запросы вашего API по сравнению с другими чтобы не упасть самому
3) ограничить число запросов по тарифному плану клиента
Вот неплохая статья про существующие алгоритмы rate limiting https://habr.com/ru/post/448438
Неплохая библиотека для Java - Bucket4J https://github.com/bucket4j/bucket4j
Развивается порядка 8 лет, к слову разработчики из России.
Вот хорошее видео от разработчиков с примерам настройки - https://www.youtube.com/watch?v=OSNFNxgZZ3A
В простых случаях можно использовать Resilience4j, удобно со Spring Boot посредством аннотаций https://www.baeldung.com/spring-boot-resilience4j Resilience4j библиотека более широкого профиля, отвечает за отказоустойчивость, см. детали в статье
#java #libraries #highload #interview_question #rate_limiters
Сегодня расскажу про такую штуку, как rate limiters.
Как следует из названия это компонент для ограничения числа запросов в интервал времени.
Может возникнуть вопрос - причем здесь Java? Да, обычно такие штуки разворачивают на инфраструктуре - например, в k8s или nginx.
Если так можно сделать - так и нужно делать)
Когда так сделать не получится:
1) алгоритм ограничения числа запросов нестандартный, поэтому нужна Java, чтобы его запрограммировать)
2) нужна возможность продвинутого мониторинга числа пропущенных и отбитых запросов
3) при изменении параметров rate limiting нужна умная ребалансировка. Т.е. нельзя просто сбросить счетчики в ноль, т.к. это приведет к падению сервиса, который защищает rate limiter.
4) ну и наконец нет подходящей инфраструктуры
Второй вопрос - в каких кейсах это может понадобиться:
1) не уронить стоящий за вами сервис
2) приоритизировать какие-то запросы вашего API по сравнению с другими чтобы не упасть самому
3) ограничить число запросов по тарифному плану клиента
Вот неплохая статья про существующие алгоритмы rate limiting https://habr.com/ru/post/448438
Неплохая библиотека для Java - Bucket4J https://github.com/bucket4j/bucket4j
Развивается порядка 8 лет, к слову разработчики из России.
Вот хорошее видео от разработчиков с примерам настройки - https://www.youtube.com/watch?v=OSNFNxgZZ3A
В простых случаях можно использовать Resilience4j, удобно со Spring Boot посредством аннотаций https://www.baeldung.com/spring-boot-resilience4j Resilience4j библиотека более широкого профиля, отвечает за отказоустойчивость, см. детали в статье
#java #libraries #highload #interview_question #rate_limiters
Хабр
Ограничение скорости обработки запросов, или как не устроить DDoS-атаку на своего клиента
Иногда при разработке highload-продукта возникает ситуация, когда надо обработать не максимально большое количество запросов, а наоборот — ограничить количество запросов в единицу времени. В нашем...
Всем привет!
Поговорим про микросервисы. Статей будет несколько, от плюсов и минусов до саги и прочих паттернов.
Для начала что такое микросервис. Я дам определение в виде набора обязательных признаков. Обязательны все из них.
1) одна команда
2) отдельная кодовая база
3) отдельная БД
4) отдельный pipeline
5) отдельный релизный цикл
6) небольшой объем кода
7) взаимодействие с другими сервисами через межпроцессное API. REST, gRPC, GraphQL, Kafka - это то, что сейчас на слуху, на самом деле технологий больше.
Для начала рассмотрим плюсы:
1) один сервис разрабатывает одна команда. При этом одна команда может делать несколько приложений, но главное здесь - у одного приложения один хозяин, определяющий вектор его развития. Такие ключевые решения, как: язык, на котором написан код, используемые библиотеки, утилита для сборки и архитектура в конце концов) Проще договорится, меньше согласований и зависимостей от внешних людей или команд. Этого же результата помогает достичь отдельный релизный цикл. Хотя в случае enterprise микросервисов зависимостей не избежать и это боль( Еще одно замечание - микросервис может релизиться независимо при условии использования фича-тогглов https://martinfowler.com/articles/feature-toggles.html и поддержки совместимости API. Альтернатива фича тогглов - писать код так, чтобы его неготовый кусок невозможно было вызывать снаружи до момента полной готовности вас и смежников.
2) МИКРОсервис означает, что кода не должно быть много. Сколько тысяч строк - явно не миллион и не сто тысяч, скорее несколько тысяч. А раз кода не много - в него проще погрузится. Меньше кривая обучения для новых членов команды. А если ты в целом понимаешь как работает приложение - с большей вероятностью доработки и рефакторинг будут сохранять его исходную архитектуру или менять ее единообразно. Как результат сервис будет оставаться понятным и далее.
3) проект быстрее компилируется и запускается, быстрее прогоняются тесты - быстрее обратная связь, быстрее процесс разработки. Проще делать маленькие Pull Request, ревьюверы меньше матерятся, т.к. не видят 100+ файлов в Pull Request, проще слияния. Вообще писать код нужно так, чтобы merge конфликтов не было, но это идеал, к которому надо стремится)
4) DevOps инструменты и практики будут работать "из коробки". На проектах с сотнями тысяч строк pipeline будет падать. И падать достаточно часто. SonarQube не может определить дельту Pull Request и падает. Checkmarx нужно дорабатывать у вендора, чтобы не падал. Джобы сборки оптимизировать, параллелить, чтобы добиться приемлемого времени сборки. Интеграционные тесты падают, т.к. контекст, необходимый для поднятия приложения, постоянно растет. База становится такой сложной, что DBA наотрез отказываются от Liquibase и накатывают скрипты руками пошагово. Число интеграций такое, что набор примочных тестов запущенный автоматически с большой вероятностью упадет и встанет вопрос - а точно нам нужны автотесты? НТшники работают по ночам. Bitbucket дико тормозит, когда размер репозитория превышает 2 Тб, а это вполне реально - ведь хранится вся история изменений. Да и в принципе по статистике чем дольше сборка и deploy, тем больше вероятность, что на jenkins slave кончится место или память и сборка упадет. И это все - только примеры из моего опыта. А суть в следующем: инструменты DevOps имеют свои ограничения по объему данных и нагрузке, и нужно либо допиливать их напильником, либо не делать таких больших монолитов. Второй путь проще)
5) если микросервис не оправдал ожиданий - его можно выкинуть и переписать. Я не говорю, что это типовая практика, я говорю, что такая опция есть. Решение принимается на уровне команды\отдела\кластера, а не вице-президента по ИТ в случае монолита)
Резюмирую - если кода меньше, его проще выводить в ПРОМ, поддерживать и если надо выкинуть.
О минусах - в следующем посте.
#microservices #сравнение
Поговорим про микросервисы. Статей будет несколько, от плюсов и минусов до саги и прочих паттернов.
Для начала что такое микросервис. Я дам определение в виде набора обязательных признаков. Обязательны все из них.
1) одна команда
2) отдельная кодовая база
3) отдельная БД
4) отдельный pipeline
5) отдельный релизный цикл
6) небольшой объем кода
7) взаимодействие с другими сервисами через межпроцессное API. REST, gRPC, GraphQL, Kafka - это то, что сейчас на слуху, на самом деле технологий больше.
Для начала рассмотрим плюсы:
1) один сервис разрабатывает одна команда. При этом одна команда может делать несколько приложений, но главное здесь - у одного приложения один хозяин, определяющий вектор его развития. Такие ключевые решения, как: язык, на котором написан код, используемые библиотеки, утилита для сборки и архитектура в конце концов) Проще договорится, меньше согласований и зависимостей от внешних людей или команд. Этого же результата помогает достичь отдельный релизный цикл. Хотя в случае enterprise микросервисов зависимостей не избежать и это боль( Еще одно замечание - микросервис может релизиться независимо при условии использования фича-тогглов https://martinfowler.com/articles/feature-toggles.html и поддержки совместимости API. Альтернатива фича тогглов - писать код так, чтобы его неготовый кусок невозможно было вызывать снаружи до момента полной готовности вас и смежников.
2) МИКРОсервис означает, что кода не должно быть много. Сколько тысяч строк - явно не миллион и не сто тысяч, скорее несколько тысяч. А раз кода не много - в него проще погрузится. Меньше кривая обучения для новых членов команды. А если ты в целом понимаешь как работает приложение - с большей вероятностью доработки и рефакторинг будут сохранять его исходную архитектуру или менять ее единообразно. Как результат сервис будет оставаться понятным и далее.
3) проект быстрее компилируется и запускается, быстрее прогоняются тесты - быстрее обратная связь, быстрее процесс разработки. Проще делать маленькие Pull Request, ревьюверы меньше матерятся, т.к. не видят 100+ файлов в Pull Request, проще слияния. Вообще писать код нужно так, чтобы merge конфликтов не было, но это идеал, к которому надо стремится)
4) DevOps инструменты и практики будут работать "из коробки". На проектах с сотнями тысяч строк pipeline будет падать. И падать достаточно часто. SonarQube не может определить дельту Pull Request и падает. Checkmarx нужно дорабатывать у вендора, чтобы не падал. Джобы сборки оптимизировать, параллелить, чтобы добиться приемлемого времени сборки. Интеграционные тесты падают, т.к. контекст, необходимый для поднятия приложения, постоянно растет. База становится такой сложной, что DBA наотрез отказываются от Liquibase и накатывают скрипты руками пошагово. Число интеграций такое, что набор примочных тестов запущенный автоматически с большой вероятностью упадет и встанет вопрос - а точно нам нужны автотесты? НТшники работают по ночам. Bitbucket дико тормозит, когда размер репозитория превышает 2 Тб, а это вполне реально - ведь хранится вся история изменений. Да и в принципе по статистике чем дольше сборка и deploy, тем больше вероятность, что на jenkins slave кончится место или память и сборка упадет. И это все - только примеры из моего опыта. А суть в следующем: инструменты DevOps имеют свои ограничения по объему данных и нагрузке, и нужно либо допиливать их напильником, либо не делать таких больших монолитов. Второй путь проще)
5) если микросервис не оправдал ожиданий - его можно выкинуть и переписать. Я не говорю, что это типовая практика, я говорю, что такая опция есть. Решение принимается на уровне команды\отдела\кластера, а не вице-президента по ИТ в случае монолита)
Резюмирую - если кода меньше, его проще выводить в ПРОМ, поддерживать и если надо выкинуть.
О минусах - в следующем посте.
#microservices #сравнение
martinfowler.com
Feature Toggles (aka Feature Flags)
Feature Flags can be categorized into several buckets; manage each appropriately. Smart implementation can help constrain complexity.
Вдогонку - забыл про два важных преимущества микросервисов не с точки зрения команды, а для компании в целом:
6) микросервис можно независимо масштабировать. Т.е. давать больше ресурсов для более нагруженных частей системы. Особенно легко это реализуется в случае stateless сервисов в облаке - через ресурс типа HorizontalPodAutoscaler. Для сервисов с состоянием тоже возможны варианты - sticky session если речь про кэширование состояния или шардирование для хранилищ данных. Фактор масштабирования стоит учитывать при разделении функционала на микросервисы.
7) если в компании есть команды, разрабатывающие на разных языках или можно купить\внедрить готовое решение - микросервисная архитектура легко позволяет это сделать, т.к. интеграция между сервисами идет через межпроцессное API
#microserices #сравнение
6) микросервис можно независимо масштабировать. Т.е. давать больше ресурсов для более нагруженных частей системы. Особенно легко это реализуется в случае stateless сервисов в облаке - через ресурс типа HorizontalPodAutoscaler. Для сервисов с состоянием тоже возможны варианты - sticky session если речь про кэширование состояния или шардирование для хранилищ данных. Фактор масштабирования стоит учитывать при разделении функционала на микросервисы.
7) если в компании есть команды, разрабатывающие на разных языках или можно купить\внедрить готовое решение - микросервисная архитектура легко позволяет это сделать, т.к. интеграция между сервисами идет через межпроцессное API
#microserices #сравнение
Всем привет!
Пару заблуждений про микросервисы.
1) Облачные технологии (k8s) не равно микросервисам. Да, если вы начинаете проект с микросервисами с нуля и есть возможность развернуть его в облаке - так и нужно делать.
Облако упрощает развертывание и масштабирование микросервисов, добавляет отказоустойчивость. Но микросервисы - это архитектура. А k8s - технологии.
Аналогия - REST обычно используют с JSON, для того же Spring RestController это настройка по умолчанию. Но никто не мешает в REST API возвращать XML.
Как я писал ранее: по большому счету микросервис - это про сознательное ограничение объема кода\функционала и связанные с этим плюшки.
2) трушный микросервис не обязан реализовывать строго одну операцию. Как именно выделять микросервисы - отдельная тема. Базовые варианты: по функционалу, по архитектурному слою - например, слой хранения - или по требованиям к масштабированию.
Но в любом из этих случаев в API, которое выставляет сервис, может быть несколько логически связанных методов. Ключевое слове здесь - логически связанных.
Если я что-то упустил, есть вопросы или возражения - пишите.
#microservices
Пару заблуждений про микросервисы.
1) Облачные технологии (k8s) не равно микросервисам. Да, если вы начинаете проект с микросервисами с нуля и есть возможность развернуть его в облаке - так и нужно делать.
Облако упрощает развертывание и масштабирование микросервисов, добавляет отказоустойчивость. Но микросервисы - это архитектура. А k8s - технологии.
Аналогия - REST обычно используют с JSON, для того же Spring RestController это настройка по умолчанию. Но никто не мешает в REST API возвращать XML.
Как я писал ранее: по большому счету микросервис - это про сознательное ограничение объема кода\функционала и связанные с этим плюшки.
2) трушный микросервис не обязан реализовывать строго одну операцию. Как именно выделять микросервисы - отдельная тема. Базовые варианты: по функционалу, по архитектурному слою - например, слой хранения - или по требованиям к масштабированию.
Но в любом из этих случаев в API, которое выставляет сервис, может быть несколько логически связанных методов. Ключевое слове здесь - логически связанных.
Если я что-то упустил, есть вопросы или возражения - пишите.
#microservices
Всем привет!
И снова микросервисы.
Из предыдущих постов видно, что разработчикам и команде в целом проще работать с микросервисами. Компании, которой принадлежит продукт, тоже, т.к. снижаются риски. Неужели так все радужно? Не совсем)
И основные трудности ложатся на плечи сопровождения и третьей линии поддержки. Причина проста - увеличивается число единиц деплоймента, увеличивается число интеграций и, следовательно, зависимостей между сервисами. Сложнее разворачивать, т.к. надо учитывать зависимости, сложнее разбирать ошибки, т.к. недостаточно посмотреть логи одного приложения как это было с монолитом. Также увеличивается риск каскадных сбоев, когда из-за сбоя одного ключевого сервиса "подвисают" его входящие сетевые соединения, переполняются пулы потоков и все падает большое количество серверов.
Что тут можно сделать?
1) с увеличением числа единиц деплоймента сделать ничего нельзя, но упросить сам процесс деплоя позволяет k8s
2) проблему сложных зависимостей между микросервисами надо решать через поддержку совместимости и версионирование API и фича тогглы. Т.е. поставщик данных при любых изменениях версионирует API какое-то время сохраняя старую версию, а потребитель включает новую фичу для клиентов по рубильнику по готовности поставщика. Это позволит избежать синхронных внедрений нескольких сервисов. Синхронные внедрения - "зло", я об этом уже писал: https://t.me/javaKotlinDevOps/24 Решение звучит просто, а реализуется исходя из моего опыта сложно) Как его добиться? Только дисциплиной, серебряной пули нет. Ну и учитывая версионирование API при проектировании сервиса, а также достаточным набором модульных и приемочных тестов чтобы не поломать API. Как определить достаточность? Очень просто: если есть чувство уверенности, что раз тесты прошли, то API не сломали - значит набор достаточен))) Для того, чтобы потребитель и поставщик одинаково представляли себе новую версию API она обязательно должна храниться в системе контроля версий (VCS). А убедиться в совместимости позволяет технология Consumer Driven Contract (CDC) https://martinfowler.com/articles/consumerDrivenContracts.html Самые известные фреймворки ее реализующие - Spring Cloud Contract и Pact.
3) проблему разбора багов и инцидентов помогают решить централизованный сбор логов и метрик, а главное - распределенная трассировка. Это технология для отслеживания всей цепочки запросов, включая список сервисов, через который прошел запрос, тайминги и информацию о возникающих ошибках. Для трассировки есть стандарт - OpenTelemetry https://opentelemetry.io/docs/concepts/what-is-opentelemetry/. Вот неплохое видео, описывающее архитектуру трассировки в целом и сравнивающее две его самые известные реализации - Zipkin и Jaeger. https://youtu.be/6PiThk3QHWw?t=4191 См. вторую часть видео, ссылка указывает на нее. А вот статья, описывающая проблемы текущих решений - https://habr.com/ru/company/flant/blog/460365/
4) решить проблему каскадных сбоев позволяют ограниченные и согласованные таймауты и реализация circuit breakers https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker Согласованность таймаутов можно обеспечить в ручном режиме, а можно передачей значений таймаута в API от клиента к серверу. Надо сказать, что данные паттерны важны и для монолита, но для микросервисов из-за увеличения числа интеграций их сложнее контролировать. Паттерны можно реализовать на клиенте, а можно с помощью Service Mesh, например, Istio - https://istio.io/latest/docs/concepts/traffic-management/#network-resilience-and-testing Последний вариант дает возможность централизованного контроля за настройкой таймаутов и circuit breaker.
#microservices #сравнение
И снова микросервисы.
Из предыдущих постов видно, что разработчикам и команде в целом проще работать с микросервисами. Компании, которой принадлежит продукт, тоже, т.к. снижаются риски. Неужели так все радужно? Не совсем)
И основные трудности ложатся на плечи сопровождения и третьей линии поддержки. Причина проста - увеличивается число единиц деплоймента, увеличивается число интеграций и, следовательно, зависимостей между сервисами. Сложнее разворачивать, т.к. надо учитывать зависимости, сложнее разбирать ошибки, т.к. недостаточно посмотреть логи одного приложения как это было с монолитом. Также увеличивается риск каскадных сбоев, когда из-за сбоя одного ключевого сервиса "подвисают" его входящие сетевые соединения, переполняются пулы потоков и все падает большое количество серверов.
Что тут можно сделать?
1) с увеличением числа единиц деплоймента сделать ничего нельзя, но упросить сам процесс деплоя позволяет k8s
2) проблему сложных зависимостей между микросервисами надо решать через поддержку совместимости и версионирование API и фича тогглы. Т.е. поставщик данных при любых изменениях версионирует API какое-то время сохраняя старую версию, а потребитель включает новую фичу для клиентов по рубильнику по готовности поставщика. Это позволит избежать синхронных внедрений нескольких сервисов. Синхронные внедрения - "зло", я об этом уже писал: https://t.me/javaKotlinDevOps/24 Решение звучит просто, а реализуется исходя из моего опыта сложно) Как его добиться? Только дисциплиной, серебряной пули нет. Ну и учитывая версионирование API при проектировании сервиса, а также достаточным набором модульных и приемочных тестов чтобы не поломать API. Как определить достаточность? Очень просто: если есть чувство уверенности, что раз тесты прошли, то API не сломали - значит набор достаточен))) Для того, чтобы потребитель и поставщик одинаково представляли себе новую версию API она обязательно должна храниться в системе контроля версий (VCS). А убедиться в совместимости позволяет технология Consumer Driven Contract (CDC) https://martinfowler.com/articles/consumerDrivenContracts.html Самые известные фреймворки ее реализующие - Spring Cloud Contract и Pact.
3) проблему разбора багов и инцидентов помогают решить централизованный сбор логов и метрик, а главное - распределенная трассировка. Это технология для отслеживания всей цепочки запросов, включая список сервисов, через который прошел запрос, тайминги и информацию о возникающих ошибках. Для трассировки есть стандарт - OpenTelemetry https://opentelemetry.io/docs/concepts/what-is-opentelemetry/. Вот неплохое видео, описывающее архитектуру трассировки в целом и сравнивающее две его самые известные реализации - Zipkin и Jaeger. https://youtu.be/6PiThk3QHWw?t=4191 См. вторую часть видео, ссылка указывает на нее. А вот статья, описывающая проблемы текущих решений - https://habr.com/ru/company/flant/blog/460365/
4) решить проблему каскадных сбоев позволяют ограниченные и согласованные таймауты и реализация circuit breakers https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker Согласованность таймаутов можно обеспечить в ручном режиме, а можно передачей значений таймаута в API от клиента к серверу. Надо сказать, что данные паттерны важны и для монолита, но для микросервисов из-за увеличения числа интеграций их сложнее контролировать. Паттерны можно реализовать на клиенте, а можно с помощью Service Mesh, например, Istio - https://istio.io/latest/docs/concepts/traffic-management/#network-resilience-and-testing Последний вариант дает возможность централизованного контроля за настройкой таймаутов и circuit breaker.
#microservices #сравнение
Telegram
(java || kotlin) && devOps
Всем привет!
Современная разработка - это микросервисы, микросервисы - это много внешних взаимодействий, а внешние взаимодействия - это API.
Каким должно быть хорошее API?
1) API должно быть версионировано. Все течет, все меняется: бизнес-требования, новые…
Современная разработка - это микросервисы, микросервисы - это много внешних взаимодействий, а внешние взаимодействия - это API.
Каким должно быть хорошее API?
1) API должно быть версионировано. Все течет, все меняется: бизнес-требования, новые…
Всем привет!
Всегда ли нужно распиливать систему на микросервисы? Не всегда.
Я вижу как минимум один кейс.
Если выполняется хотя бы одно условие:
1) у вас одна команда
2) сроки ограничены
3) деньги ограничены
3) речь про стартап
4) создается приложение для проверки гипотезы
- стоит рассмотреть вариант с монолитом.
Плюсы - потребуется меньше железа, проще настраивать пайплайн и инфраструктуру. В простейшем случае можно весь ПРОМ развернуть на одном сервере. В случае стартапа или проверки гипотезы когда ещё не ясно как правильно разделить систему на независимые контексты ещё не понятно - в случае монолита ее проще рефакторить. Пока он маленький)
Может возникнуть вопрос - а как дальше масштабировать? Ответ - делите систему на уровне модулей Maven\Gradle, контролируйте зависимости между уровнями приложения, избегайте циклических ссылок. Для всего этого есть утилиты, напишу о них далее. Ну и конечно нужен набор приемочных тестов, его можно реализовать в период разделения на микросервисы, запуская вначале на "монолите", потом на микросервисах. С точки зрения БД - храните данные в разных схемах или хотя бы таблицах. Первый вариант лучше и одновременно хуже тем, что между схемами невозможны транзакции. Проектирование с использованием DDD - Domain driven development - в частности концепция агрегата, тоже хороший инструмент для создания разделяемого монолита. Тогда из этих модулей можно будет в будущем сделать микросервисы. Да, в любом случае при разделении потребуется дополнительная работа, но зато значительно увеличивается время вывода в ПРОМ и получение обратной связи. А дополнительную работу предлагаю рассматривать как рефакторинг.
Какие риски у этого подхода - по большому счету один. Если маленький монолит, который задумывался временным решением, превратится в большой и станет постоянным. Тогда в какой-то момент технологии устареют, части монолита срастутся сильнее и возникнет вопрос - а стоит ли его вообще разделять? Или проще переписать заново)))
И главное, что стоит запомнить - у каждого микросервиса должна быть веская причина существования. Если есть сомнения - нужен ли еще микросервис, не надо его выделять. Микросервис - далека не бесплатная штука в плане разработки и поддержки
#microservices #сравнение
Всегда ли нужно распиливать систему на микросервисы? Не всегда.
Я вижу как минимум один кейс.
Если выполняется хотя бы одно условие:
1) у вас одна команда
2) сроки ограничены
3) деньги ограничены
3) речь про стартап
4) создается приложение для проверки гипотезы
- стоит рассмотреть вариант с монолитом.
Плюсы - потребуется меньше железа, проще настраивать пайплайн и инфраструктуру. В простейшем случае можно весь ПРОМ развернуть на одном сервере. В случае стартапа или проверки гипотезы когда ещё не ясно как правильно разделить систему на независимые контексты ещё не понятно - в случае монолита ее проще рефакторить. Пока он маленький)
Может возникнуть вопрос - а как дальше масштабировать? Ответ - делите систему на уровне модулей Maven\Gradle, контролируйте зависимости между уровнями приложения, избегайте циклических ссылок. Для всего этого есть утилиты, напишу о них далее. Ну и конечно нужен набор приемочных тестов, его можно реализовать в период разделения на микросервисы, запуская вначале на "монолите", потом на микросервисах. С точки зрения БД - храните данные в разных схемах или хотя бы таблицах. Первый вариант лучше и одновременно хуже тем, что между схемами невозможны транзакции. Проектирование с использованием DDD - Domain driven development - в частности концепция агрегата, тоже хороший инструмент для создания разделяемого монолита. Тогда из этих модулей можно будет в будущем сделать микросервисы. Да, в любом случае при разделении потребуется дополнительная работа, но зато значительно увеличивается время вывода в ПРОМ и получение обратной связи. А дополнительную работу предлагаю рассматривать как рефакторинг.
Какие риски у этого подхода - по большому счету один. Если маленький монолит, который задумывался временным решением, превратится в большой и станет постоянным. Тогда в какой-то момент технологии устареют, части монолита срастутся сильнее и возникнет вопрос - а стоит ли его вообще разделять? Или проще переписать заново)))
И главное, что стоит запомнить - у каждого микросервиса должна быть веская причина существования. Если есть сомнения - нужен ли еще микросервис, не надо его выделять. Микросервис - далека не бесплатная штука в плане разработки и поддержки
#microservices #сравнение
Всем привет!
Поговорим про разделение функционала между микросервисами.
Для начала я бы разделил два случая - распил монолита или создание нового приложения.
При распиле есть несколько путей, которые можно комбинировать:
1) отделять в первую очередь менее значительный функционал. Так можно будет набить шишки, настроить DevOps, инфраструктуру, а потом уже переходить к чему-то серьёзному
2) отделять функционал, который легче выделить. Например, он уже компилируется в отдельный war/ear, хотя и имеет общий релизный цикл с монолитом. Или он правильно спроектирован https://t.me/javaKotlinDevOps/59 и его отделение требует минимальных усилий.
3) делать новые фичи на микросервисах, закрывая монолит API Gateway для единообразия API.
Все это называется шаблоном Душитель https://microservices.io/patterns/refactoring/strangler-application.html Душим мы как вы понимаете монолит)
Если же мы делаем новый функционал - тоже есть разные варианты, размещу их в порядке приоритета
1) разделение по бизнес фичам. Где фича - это агрегат в терминах DDD. Или ресурс в REST. Как я уже говорил ранее - не операция, это слишком мелко https://t.me/javaKotlinDevOps/59
2) разделение по слоям. Например, можно выделить в отдельный сервис сохранение данных. Или шлюз к смежной системе
3) разделение по планируемой нагрузке. Я бы его применял как дополнительный фактор к первым двум. Более нагруженные сервисы выделяем отдельно.
Еще один важный фактор: возможность переиспользования сервиса. Имеет значение и при распиле монолита, и при разработке новых фичей. Пример: отправка уведомлений пользователю по-хорошему стандартизирована и такой сервис смогут переиспользовать все создаваемые микросервисы. Способствуем выполнению принципа DRY - https://ru.wikipedia.org/wiki/Don’t_repeat_yourself
И напоследок хотел бы напомнить простую истину - как нет серебряной пули или единственно верной архитектуры, так нет канонического способа разделения на микросервисы)
#microservices #сравнение
Поговорим про разделение функционала между микросервисами.
Для начала я бы разделил два случая - распил монолита или создание нового приложения.
При распиле есть несколько путей, которые можно комбинировать:
1) отделять в первую очередь менее значительный функционал. Так можно будет набить шишки, настроить DevOps, инфраструктуру, а потом уже переходить к чему-то серьёзному
2) отделять функционал, который легче выделить. Например, он уже компилируется в отдельный war/ear, хотя и имеет общий релизный цикл с монолитом. Или он правильно спроектирован https://t.me/javaKotlinDevOps/59 и его отделение требует минимальных усилий.
3) делать новые фичи на микросервисах, закрывая монолит API Gateway для единообразия API.
Все это называется шаблоном Душитель https://microservices.io/patterns/refactoring/strangler-application.html Душим мы как вы понимаете монолит)
Если же мы делаем новый функционал - тоже есть разные варианты, размещу их в порядке приоритета
1) разделение по бизнес фичам. Где фича - это агрегат в терминах DDD. Или ресурс в REST. Как я уже говорил ранее - не операция, это слишком мелко https://t.me/javaKotlinDevOps/59
2) разделение по слоям. Например, можно выделить в отдельный сервис сохранение данных. Или шлюз к смежной системе
3) разделение по планируемой нагрузке. Я бы его применял как дополнительный фактор к первым двум. Более нагруженные сервисы выделяем отдельно.
Еще один важный фактор: возможность переиспользования сервиса. Имеет значение и при распиле монолита, и при разработке новых фичей. Пример: отправка уведомлений пользователю по-хорошему стандартизирована и такой сервис смогут переиспользовать все создаваемые микросервисы. Способствуем выполнению принципа DRY - https://ru.wikipedia.org/wiki/Don’t_repeat_yourself
И напоследок хотел бы напомнить простую истину - как нет серебряной пули или единственно верной архитектуры, так нет канонического способа разделения на микросервисы)
#microservices #сравнение
Telegram
(java || kotlin) && devOps
Всем привет!
Всегда ли нужно распиливать систему на микросервисы? Не всегда.
Я вижу как минимум один кейс.
Если выполняется хотя бы одно условие:
1) у вас одна команда
2) сроки ограничены
3) деньги ограничены
3) речь про стартап
4) создается приложение…
Всегда ли нужно распиливать систему на микросервисы? Не всегда.
Я вижу как минимум один кейс.
Если выполняется хотя бы одно условие:
1) у вас одна команда
2) сроки ограничены
3) деньги ограничены
3) речь про стартап
4) создается приложение…
Всем привет!
Хочу разбавить тему микросервисов. Сегодня поговорим про Spring и Dependency Injection (DI).
Есть три способа внедрения бина:
1) через конструктор
2) через поле
3) через setter
Практически все слышали, что предпочтительнее внедрять через конструктор. Вопрос почему?
Первая и самая главная причина: внедрение зависимостей - это часть инициализации объекта. А конструктор - это простой и естественный способ инициализировать объект.
Что из этого следует:
1) список внедряемых бинов легко читается. Через setter-ы очень плохо читается, через поля получше, но конструктор вне конкуренции.
2) становится проще создать полностью инициализированный объект т.к. для этого есть готовый конструктор. Полезно в тестах, можно написать тест на чистом JUnit, без @SpringBootTest и других инструментов для инициализации контекста из Spring Test.
3) если классу нужно слишком много бинов для работы - SonarQube будет ругаться, что у конструктора слишком много полей. Считаю это плюсом, если ругается - это повод задуматься над рефакторингом
4) если у бинов циклические ссылки - инициализация контекста Spring упадет. Многие считают это минусом, но я не согласен: чем раньше найдешь циклическую зависимость - тем быстрее исправишь. См. https://t.me/javaKotlinDevOps/53
5) если с внедряемыми бинами надо что-то делать, то у нас есть место, где гарантированно все бины будут доступны - конструктор. При внедрении зависимостей через setter или поля вначале выполнится дефолтный конструктор, потом будут проиницилизированы поля.
6) для инициализации не используется рефлексия, как в случае autowired полей, т.е. инициализации работает немного быстрее
7) если конструктор единственный, то начиная со Spring 4.3 не нужно указывать аннотацию @Autowired. Для Kotlin в случае default конструктора есть особенности, для того, чтобы с ними не сталкиваться лучше использовать Spring 5+ ) Не сказать, что это большое преимущество, т.к. аннотацию для маркировки бина все равно придется использовать, поэтому класс без import Spring зависимостей так просто сделать не получится.
И второй важный момент - поддержка иммутабельности объектов, т.к. только в конструкторе можно инициализировать final поля в случае Java и val - в случае Kotlin.
#spring #java #kotlin #interview_question
Хочу разбавить тему микросервисов. Сегодня поговорим про Spring и Dependency Injection (DI).
Есть три способа внедрения бина:
1) через конструктор
2) через поле
3) через setter
Практически все слышали, что предпочтительнее внедрять через конструктор. Вопрос почему?
Первая и самая главная причина: внедрение зависимостей - это часть инициализации объекта. А конструктор - это простой и естественный способ инициализировать объект.
Что из этого следует:
1) список внедряемых бинов легко читается. Через setter-ы очень плохо читается, через поля получше, но конструктор вне конкуренции.
2) становится проще создать полностью инициализированный объект т.к. для этого есть готовый конструктор. Полезно в тестах, можно написать тест на чистом JUnit, без @SpringBootTest и других инструментов для инициализации контекста из Spring Test.
3) если классу нужно слишком много бинов для работы - SonarQube будет ругаться, что у конструктора слишком много полей. Считаю это плюсом, если ругается - это повод задуматься над рефакторингом
4) если у бинов циклические ссылки - инициализация контекста Spring упадет. Многие считают это минусом, но я не согласен: чем раньше найдешь циклическую зависимость - тем быстрее исправишь. См. https://t.me/javaKotlinDevOps/53
5) если с внедряемыми бинами надо что-то делать, то у нас есть место, где гарантированно все бины будут доступны - конструктор. При внедрении зависимостей через setter или поля вначале выполнится дефолтный конструктор, потом будут проиницилизированы поля.
6) для инициализации не используется рефлексия, как в случае autowired полей, т.е. инициализации работает немного быстрее
7) если конструктор единственный, то начиная со Spring 4.3 не нужно указывать аннотацию @Autowired. Для Kotlin в случае default конструктора есть особенности, для того, чтобы с ними не сталкиваться лучше использовать Spring 5+ ) Не сказать, что это большое преимущество, т.к. аннотацию для маркировки бина все равно придется использовать, поэтому класс без import Spring зависимостей так просто сделать не получится.
И второй важный момент - поддержка иммутабельности объектов, т.к. только в конструкторе можно инициализировать final поля в случае Java и val - в случае Kotlin.
#spring #java #kotlin #interview_question
Telegram
(java || kotlin) && devOps
Всем привет!
Сегодня рассмотрим циклические зависимости. Начнем с уровня классов и дойдем до слоев приложения.
1) классы. Технически Java компилятор умеет компилировать взаимозависимые классы за счет того, что является многопроходным - https://ru.wikip…
Сегодня рассмотрим циклические зависимости. Начнем с уровня классов и дойдем до слоев приложения.
1) классы. Технически Java компилятор умеет компилировать взаимозависимые классы за счет того, что является многопроходным - https://ru.wikip…
Всем привет!
Продолжается перерыв в теме микросервисов.
Сегодня будет немного холивара)
Можно ли использовать static методы?
Исторически static-и прошли 3 стадии в своем восприятии.
1 этап: о круто, можно не создавать объект, давайте все методы делать статическими.
Если что - я конечно утрирую насчет всех, но static-и активно использовались, это факт, который легко увидеть в legacy коде. Еще факт: static-и есть во многих языках, что как бы намекает. Даже в Kotlin они есть, просто выглядят странно - я про companion object.
2 этап: static-и трудно тестировать, это антипаттерн, не надо их использовать. Ну разве что для Util классов, и то ...
Вот пример, демонстрирующий почему возникают такие мысли.
Возьмем другой антипаттерн - синглетон.
class Singleton {
private static final instance = new Singleton();
public static Singleton getInstance() {
return instance;
}
....
}
Сразу скажу - это не одна из простейших реализаций, не потокобезопасная, взятая для примера, так делать не надо.
Предположим, мы хотим сделать вместо Singleton заглушку для теста. Ну например, он ходит в БД или читает данные из файла, а мы хотим, чтобы тесты работали быстро.
Можно сделать так:
class TestSingleton extends Singleton {
private static final testInstance = new TestSingleton();
public static Singleton getTestInstance() {
return testInstance;
}
....
}
Но это работает только если Sigleton можно как-то передать в тестируемый класс, он же System under Test (SUT).
А если это зависимость зависимости SUT? Или в более общем случае его нельзя передать через public API?
Основная проблема в том, что static методы не наследуются, а следовательно переопределить их нельзя. Можно создать метод с тем же именем, но вызываться будет метод того класса, который указан в конкретном куске кода. Или декларируемого, а не фактического класса переменной, поля или параметра, если static вызывается на объекте. В этом плане Java позволяя вызывать static метод из объекта только путает людей( К слову, в Kotlin так нельзя.
Есть конечно грязные хаки с мокированием static методов, даже Mockito это умеет. Но тот факт, что для включения этой фичи нужно добавить настройку в classpath https://www.baeldung.com/mockito-mock-static-methods говорит о том, что авторы Mockito не рекомендуют так делать.
3 этап, наше время: все не так однозначно. Точнее однозначно вот что: если static метод используется в паре со static полями - это точно зло.
И самостоятельное создание синглетонов тоже зло) Это я на всякий случай уточняю)
Но если присмотрется к вот такому static методу:
1) он не имеет доступа к полям объекта по определению
2) в классе нет static полей как я писал выше
3) пусть метод не имеет побочных эффектов. Т.е. не лезет в БД, в файловую систему, в другие сервисы
Т.е метод получает что-то на вход, вычисляет что-то и возвращает результат.
Это типичный метод Util класса, да.
Но еще это определение функции из математики. А функция - это функциональное программирование. А Java начиная с 8 версии умеет передавать ссылки на функции. И хотя в ней нет функциональных типов, но есть функциональные интерфейсы, которые делают тоже самое, просто немного с большим количеством кода. Java же, все как мы любим)
Подводя итог - считать static злом не надо. Надо лишь правильно его использовать.
#interview_question #holy_war #java #kotlin
Продолжается перерыв в теме микросервисов.
Сегодня будет немного холивара)
Можно ли использовать static методы?
Исторически static-и прошли 3 стадии в своем восприятии.
1 этап: о круто, можно не создавать объект, давайте все методы делать статическими.
Если что - я конечно утрирую насчет всех, но static-и активно использовались, это факт, который легко увидеть в legacy коде. Еще факт: static-и есть во многих языках, что как бы намекает. Даже в Kotlin они есть, просто выглядят странно - я про companion object.
2 этап: static-и трудно тестировать, это антипаттерн, не надо их использовать. Ну разве что для Util классов, и то ...
Вот пример, демонстрирующий почему возникают такие мысли.
Возьмем другой антипаттерн - синглетон.
class Singleton {
private static final instance = new Singleton();
public static Singleton getInstance() {
return instance;
}
....
}
Сразу скажу - это не одна из простейших реализаций, не потокобезопасная, взятая для примера, так делать не надо.
Предположим, мы хотим сделать вместо Singleton заглушку для теста. Ну например, он ходит в БД или читает данные из файла, а мы хотим, чтобы тесты работали быстро.
Можно сделать так:
class TestSingleton extends Singleton {
private static final testInstance = new TestSingleton();
public static Singleton getTestInstance() {
return testInstance;
}
....
}
Но это работает только если Sigleton можно как-то передать в тестируемый класс, он же System under Test (SUT).
А если это зависимость зависимости SUT? Или в более общем случае его нельзя передать через public API?
Основная проблема в том, что static методы не наследуются, а следовательно переопределить их нельзя. Можно создать метод с тем же именем, но вызываться будет метод того класса, который указан в конкретном куске кода. Или декларируемого, а не фактического класса переменной, поля или параметра, если static вызывается на объекте. В этом плане Java позволяя вызывать static метод из объекта только путает людей( К слову, в Kotlin так нельзя.
Есть конечно грязные хаки с мокированием static методов, даже Mockito это умеет. Но тот факт, что для включения этой фичи нужно добавить настройку в classpath https://www.baeldung.com/mockito-mock-static-methods говорит о том, что авторы Mockito не рекомендуют так делать.
3 этап, наше время: все не так однозначно. Точнее однозначно вот что: если static метод используется в паре со static полями - это точно зло.
И самостоятельное создание синглетонов тоже зло) Это я на всякий случай уточняю)
Но если присмотрется к вот такому static методу:
1) он не имеет доступа к полям объекта по определению
2) в классе нет static полей как я писал выше
3) пусть метод не имеет побочных эффектов. Т.е. не лезет в БД, в файловую систему, в другие сервисы
Т.е метод получает что-то на вход, вычисляет что-то и возвращает результат.
Это типичный метод Util класса, да.
Но еще это определение функции из математики. А функция - это функциональное программирование. А Java начиная с 8 версии умеет передавать ссылки на функции. И хотя в ней нет функциональных типов, но есть функциональные интерфейсы, которые делают тоже самое, просто немного с большим количеством кода. Java же, все как мы любим)
Подводя итог - считать static злом не надо. Надо лишь правильно его использовать.
#interview_question #holy_war #java #kotlin
Baeldung
Mocking Static Methods With Mockito | Baeldung
Explore a couple of examples of how we can use Mockito to mock static methods.