Хэширование в Java. Часть 2.

Hash таблицы.

Используя HashMap, мы используем хэш таблицу. А именно используем объект, который содержит в себе ключ и значение, которое хотим связать с этим ключом. Этот ключ затем хэшируется, а полученный хэш-код используется как индекс, в котором значение хранится в таблице.

Каждый элемент массива — своеобразная «корзина» или bucket, которая хранит связанный список со значением.

HashMap использует для хранения пары — на каждый ключ приходится только одно значение. То есть связанный список будет состоять из одного элемента, а ссылаться этот элемент будет на null — специальное «пустое» значение. Если бы в такой структуре значений было несколько, первое ссылалось бы на второе и так далее — так устроен связанный список.

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

Для оптимизации доступа используется хэш ключа. Когда в HashMap добавляют ключ и значение, для ключа сразу высчитывается хэш. По нему определяется позиция в массиве для этой пары: для расчета есть специальные формулы.

HashMap — динамическая структура, то есть количество «корзинок» может изменяться. По умолчанию сущность создается с 16 «корзинками», но это поведение можно поменять при создании, для чего надо задать хэш-таблице начальный размер вручную. Когда элементов в ней становится больше, чем корзинок, структура удлиняется — перезаписывает массив на новый, с большей длиной. По умолчанию длина увеличивается вдвое.

У HashMap, как и у всех подобных структур, есть набор своих методов — функций, которые позволяют удобно работать с данными. Для добавления, поиска, перезаписи или удаления элемента есть свои команды; также можно перебирать элементы и ключи и делать многое другое.

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

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Тот самый коллега на удалёнке в Таиланде

✅ JavaStart. Подписаться

Хэширование в Java. Часть 3.

Коллизии Hash таблиц и их предотвращение.

В идеальной ситуации хэш полностью индивидуален для каждого уникального объекта. Но в реальности хэши могут совпадать у совершенно разных объектов. Это происходит из-за несовершенства существующих алгоритмов.

Может случиться так, что у двух разных ключей окажется одинаковый хэш. Или хэш будет разным, но по формуле позиция для обоих хэшей будет одинаковой. Тогда значения обоих ключей окажутся записаны в одну «корзинку» или bucket. Это и есть коллизия.

Именно из-за коллизий для хранения значений используется связанный список: если бы в массиве просто хранился объект, любая коллизия перезаписала бы текущее значение, а это опасно. А при текущей реализации, даже если случится коллизия, новое значение просто запишется в начало той же «корзинки», не изменив старое.

Если такое случится, структура потеряет эффективность и будет работать медленнее, поэтому коллизий все равно лучше не допускать, но сами данные останутся целы.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Хэширование в Java. Часть 4.

HashMap умеет отличать коллизию от реальной перезаписи элемента.

🔞 Обратите внимание, это очень важный пункт, практически всегда на собеседовании вас спросят об этом!

Когда структуре дают новую пару «ключ–значение», она проверяет, есть ли в массиве такие хэши и такие ключи.

Результат такой:

1) если таких хэшей и ключей нет, в хэш–таблицу просто добавляется новая пара;

2) если такой ключ есть, это перезапись — структура переписывает элемент с таким же ключом;

3) если такого ключа нет, но хэш есть — это коллизия, новое значение записывается в ту же «корзинку» или bucket за предыдущим.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Что такое CI/CD в процессе разработки ПО?

Очень распространенный вопрос на собеседовании Junior Java разработчика и trainee (стажера). Даже не с точки зрения знаете ли вы это глубоко или нет, а с точки зрения знакомы ли с этим и насколько. Так что хорошо бы знать ответ, не правда ли?)

Давайте разбираться!

CI – это акроним от Continuous Integration, а CD – это акроним от Continuous Delivery.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

CI/CD – это одна из DevOps-практик. Она также относится и к agile–практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес–требований, на качестве кода и безопасности.

Непрерывная интеграция (CI) – это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку
большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.

В пример приведу всем известный GitHub или BitBucket. Также сюда можно отнести статические анализаторы кода, которые используются при разработке, это Codacy или SonarQube.

Непрерывная поставка (CD) начинается там, где заканчивается непрерывная интеграция. Она автоматизирует развертывание приложений в различные окружения: большинство разработчиков работают как с продакшн–окружением, так и со средами разработки и тестирования.

Здесь в пример можно привести платформы/инструменты для деплоя (развертывания) приложения на какое–нибудь серверное окружение (тот же самый продакшн), например, Jenkins или сервис от Microsoft – Azure. Также к CD можно отнести системы мониторинга уже задеплоенного проекта/приложения – например, DataDog, – сервис для записи логов и отлавливания ошибок на сервере.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Let's hope!

✅ JavaStart. Подписаться

Тестирование ПО. Часть 1.

Тестирование – это очень важный процесс в разработке ПО. Серьезно, настоящий разработчик должен уметь не только писать код, решая задачу, которую хочет бизнес, но и тестировать свое решение.

Тестирование в разработке – это, Иными словами, проверка правильности работы нашей программы в тех или иных ситуациях.

Видов тестирования, методик, разделов существует очень много, все они углубленно изучаются отдельными специалистами – тестировщиками (ручными или авто). Я же остановлюсь непосредственно на основных видах тестирования, которые используем мы – Java разработчики.

Тут все просто – будем опираться на пирамиду тестирования Майка Кона (на картинке).

Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме.
Данные тесты покрывают маленькие кусочки кода и весьма легковесные, не кушающие много ресурсов (под ресурсами я имею виду оперативную память и время).

Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее.

Как пример интеграционных тестов можно рассмотреть соединение с базой данных и проверку правильной отработки методов, работающих с ней.

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

На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Что вернет метод, если value = null?

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Тестирование ПО. Часть 2.1. Ключевые понятия юнит–тестирования.

Покрытие тестов (Code Coverage) — одна из главных оценок качества тестирования приложения. Это процент кода, который был покрыт тестами (0–100%).

На практике многие гонятся за этим процентом, с чем я не согласен, так как начинается навешивание тестов там, где они не нужны. Например, у нас в сервисе есть стандартные CRUD (create/get/update/delete) операции без дополнительной логики. Эти методы — сугубо посредники, делегирующие работу слою, работающему с репозиторием (для взаимодействия с базой данных). В данной ситуации нам нечего тестировать: разве то, что вызывает ли данный метод — метод из дао, но это не серьёзно 😅

TDD (Test–driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Основная цель TDD – сделать код более понятным, простым и без ошибок.

Подход состоит из таких составляющих:

– Пишем наш тест.
– Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть 😄).
– Добавляем код, который должен удовлетворить данный тест (запускаем тест).
– Выполняем рефакторинг кода.
– That's it.

Продолжим дальше говорить о других ключевых понятиях.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться