24 октября 2019 года я впервые выступил на конференции Codemotion в Милане, Италия. Я говорил о функциональном программировании и о том, как оно может облегчить нашу жизнь при решении сложных реальных проблем, таких как ремонтопригодность, масштабируемость и обработка ошибок.

Многие спрашивали меня: «Когда бы вы порекомендовали начать с FP?» Ответ прост. Если бы в 80-е задали тот же вопрос, я бы ответил совершенно иначе. Но сегодня, когда фронтенд-разработка становится все более сложной, я бы рекомендовал начать с функционального TypeScript.

Почему? Давайте выясним!

Неопределенность

По своей сути функциональное программирование заставляет вас писать чистую функцию по простой причине: нам нужно получить детерминированные результаты наших вычислений. Например, если мы имеем дело с функцией, которая зависит от ввода пользователя… сколько вещей может пойти не так? Пользователь мог ввести неправильный или неполный ввод; соединение может выйти из строя, для отправки данных на сервер может потребоваться HTTP-запрос, который может завершиться ошибкой по нескольким причинам ... мы никогда не уверены, что все пойдет так, как мы предполагали. Как, черт возьми, мы можем получить детерминированный результат из этого беспорядка? Ставить везде try/catch? Создание огромной структуры управления if/else? Мы знаем более изящный способ. В статье «Обработка try/catch и if/else hell» мы увидели, как монады могут помочь нам улучшить поток кода и повысить отказоустойчивость.

• Данные могут вызвать ошибку? Воспользуемся монадой Either. Он всегда будет возвращать два значения: Right() и Left().
• По какой причине Данные могут быть null или undefined? Может, монада придет на помощь! Наши данные будут заключены внутрь Just(),если они существуют. В противном случае у нас будет просто значение Nothing, которое нужно обработать. Больше нет null/ undefined/ void 0.
• Данные существуют, но у нас есть одна или несколько их копий? Список монада будет вашим другом!
• Зависят ли данные от штата? Государственная монада вам очень поможет!

И так далее, и так далее!

Какой в ​​этом смысл? Мы всегда будем получать предсказуемые результаты из неопределенных операций при составлении функций.

Типы

Вначале я сказал, что порекомендую Functional Typescript. Но действительно ли нам нужны типы, чтобы сделать наш код функциональным? Нет конечно. Erlang, Elixir, LISP, лишь краткий список функциональных языков с динамической типизацией. У этих языков есть несколько веских причин для использования динамической типизации. Они часто предлагают некоторые инструменты анализа, такие как Erlang's Dialyzer, который представляет собой «инструмент статического анализа, который выявляет несоответствия программного обеспечения, такие как ошибки определенного типа, код, который стал мертвым или недоступным из-за ошибки программирования, и ненужные тесты в отдельных модулях Erlang или целых (наборах) приложений.”

В JavaScript нет ничего подобного из коробки, поэтому нам нужно принять некоторые меры предосторожности. Flow и TypeScript - это всего лишь пара примеров того, как сообщество JavaScript пытается избежать некоторых хорошо известных ошибок типов времени выполнения, и они делают потрясающую работу. Они также помогают нам легче читать наш код. Сколько раз вы запускали свой JS-код с помощью отладчика из-за ошибок типа? И насколько сложно было идентифицировать этот досадный тип ошибки в вашем коде? Что ж, это может быть тривиально, но с Flow или TypeScript вы больше никогда не получите эти ошибки.

Когда вы пишете на строго типизированных функциональных языках, таких как Haskell или Idris, вы лучше смотрите на свои данные.

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

Зачем начинать с функционального интерфейса?

По простой причине: вы сразу увидите результат. Предположим на мгновение, что мы пишем платформу для ведения блогов, такую ​​как WordPress, с нуля, используя Laravel, Spring или Ruby on Rails. Пользователь входит в систему, и на сервере возникает ошибка. Нет проблем, мы отправляем ошибку во фронтенд, и пользователь будет предупрежден. Наши внутренние потоки часто хорошо определены, и мы привыкли обрабатывать эти ошибки.

Но на фронтенде может случиться все, что угодно. Мы постоянно пытаемся справиться с десятками ошибок, которые могут произойти из-за неожиданного поведения пользователя. И даже если пользователь использует наш интерфейс должным образом, подключение к Интернету может отключиться; сервер вылетает. По какой-то причине сторонний скрипт взаимодействует с нашей кодовой базой JavaScript и вызывает сбой.

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

При написании фронтенд-приложения на JavaScript нужно иметь в виду еще одну вещь: размер скрипта. Хорошо, мы были в 2020 году, и у нас есть быстрое подключение к Интернету даже в горах, но почему наши пользователи должны загружать скрипт 5 МБ для просмотра нашего веб-сайта?

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

Заключение

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

Я считаю, что JavaScript - это лингва-франка между интерфейсом и сервером. Таким образом, будет легче перенести ваши знания FP от фронтенд-разработки к бэкэнд-разработке и наоборот. Во Frontend также есть несколько интересных случаев (как мы видели ранее), когда FP действительно может иметь значение.

Итак, мой ответ всем, кто задается вопросом, с чего начать в FP: начните с JavaScript. Если вы не знакомы с TypeScript / Flow, попробуйте. Они навсегда изменят ваш способ написания JS!

Когда вы будете уверены в функциональности JS, переключиться на другие языки станет намного проще!