Введение
Во время многочисленных обзоров кода в моей профессиональной карьере я снова и снова сталкиваюсь с шаблоном проектирования, согласно которому разработчик просматривает локальный кеш, прежде чем запрашивать удаленную базу данных, чтобы избежать ненужной загрузки. К сожалению, это всегда делается последовательно. Следующий рисунок иллюстрирует это:
В случае входящих запросов сначала проверяется локальный кеш, чтобы увидеть, есть ли в нем запрошенный ресурс. Если это не так, то выполняется поиск в удаленной базе данных и отправляется ответ. Этот поиск источников данных можно элегантно оптимизировать с помощью Futures, распараллелив доступ к источникам данных:
Что такое будущее?
Будущее — это заполнитель для результата асинхронной операции, который будет доступен в какой-то момент.
Цель
Будущее можно передать в качестве аргумента вызову другой процедуры до ее результата, чтобы этот вызов можно было оценить ранее.
Пример кода на Scala
Большинство операций с фьючерсами в Scala требуют неявного ExecutionContext в своей области видимости. Это реализация стратегии асинхронного выполнения кода Future. Язык программирования Scala предлагает такую реализацию в пакете scala.concurrent, который просто распределяет фьючерсы по потокам в пуле. Технологии экосистемы Scala обычно предлагают собственную реализацию. Синтаксически код, который должен выполняться асинхронно, передается в Future между фигурными скобками. Метод find предоставляет новое будущее, которое содержит результат первого непровалившегося будущего из списка фьючерсов в необязательном виде. Если все фьючерсы потерпели неудачу, необязательный параметр содержит константу None вместо конкретного пользователя.
Заключительные слова
Как обозреватель кода я замечаю, что сотрудники по-прежнему мыслят последовательно, хотя аппаратное обеспечение и API-интерфейсы современных языков программирования уже давно позволяют параллельное программирование. Это устарело и влияет на работу пользователей. Чтобы противодействовать этому, сотрудники должны быть обучены текущему состоянию дел. В конце обучения разработчик программного обеспечения — также в роли рецензента — должен следить за тем, где реактивные конструкции будут уместны.
Искренне Ваш,
Давид Локек
