Коллизия хэш-мапы

🟠 lvl: mid+

👆В предыдущих сериях мы узнали о Hashable и для чего он нужен. Сейчас же поговорим о коллизиях хэша.

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

До этого стандарта разработчики страдали частой коллизией, особенно работая с цветами.

ℹ️ Коллизия происходит, когда разные входные данные производят одинаковый хэш, но значения не равны

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

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

Детальнее можно познакомиться отличном материале SE-0206

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

Однако мы можем улучшить её, адаптировав хэш-функцию к своему домену.

- Почитать о производительности Hasher в треде с сеньором-помидором из яблока
- Мощненькое чтиво про приемы хэширования

Рубрика "офигенные подгоны".

Смотрите че нашел, целая куча книг просто так бесплатно в гите

Спасибо бэтмену за чистый Готэм 🤡

https://github.com/wuzhouhui/misc

Зачем нужны юнит-тесты?

Частое заблуждение, что на мобилке юнит-тесты не нужны. Достаточно лишь е2е и UI.

На практике же е2е покрывает только пару успешных кейсов, забывая про остальные состояния флоу или функциональности. Он не выходит за границы UI и не погружается на уровни бизнес-логики. Его выполнение дорогое и долгое. Например, часто он не смотрит подгрузилась ли модель, закэширована ли сессия, правильны ли входящие/исходящие данные. Но он идеально подходит для проверки нескольких модулей.

Обычно е2е проходят по самому простому пути:
1. Выполняю флоу
2. Смотрю, есть ли текст, кнопка, вьюха в иерархии вьюх, которые видит пользователь.

А что там под копотом никто не хочет тестировать.

Любые тесты экономят вам время, документируют код, удешевляют разработку, помогают стабильно расти продукту. Все это ощущается на долгосрочной дистанции, когда вы устали протыкивать сложнейшие кейсы в тысячный раз. И самые дешевые — это юнит

Какова же цель юнит-тестирования? ❓

Его цель — обеспечение стабильного роста программного проекта. Ключевым словом здесь является «стабильный». В начале жизни проекта развивать его довольно просто. Намного сложнее поддерживать это
развитие с прошествием времени.

❓Чем же хороши юнит тесты?

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

Удешевление разработки
Стандартная тема, что после нескольких месяцев, лет разработки всех кейсов уже никто не помнит, часть людей меняется, требования противоречат коду. Ручных проверок слишком много. Тест позволяет найти баги на этапе разработки. Зафиксировать поведение и гарантировать, что этот кейс был проверен.

Ускорение разработки
Ну и понятно, что ручной кейс намного медленней, чем пару сотен миников

Но различия между хорошими и плохими тестами не ограничиваются вкусами. Далее разберемся в отличиях хорошего и плохого теста.