что такое сайд эффект
Осторожно! Возможны побочные эффекты
Ежемесячная рассылка CSSSR
Новости, свежие статьи и многое другое
Поделиться
Начинать нужно с того, что сеет сомнение.
Типичный фронтенд
Давайте посмотрим на простой пример фронтенд-кода:
Что является результатом работы этой функции?
От чего зависит эта функция?
Теперь давайте скроем реализацию функции и ещё раз посмотрим на неё:
Хм, теперь кажется, что функция ни от чего не зависит и вообще ничего не делает. В целом всё логично — не видя реализации функции, мы не можем определить её действие. Давайте посмотрим на другую функцию:
И скроем её реализацию:
Два вида функций
sum берёт зависимые значения только из списка аргументов и возвращает результат только при помощи оператора return — то есть взаимодействует с окружающим кодом только через стандартные механизмы вызова функции.
Такие функции называются чистыми (pure).
app же, наоборот, в качестве аргументов использует данные, которые попадают в неё неявно (не через список аргументов), и возвращает результат своей работы неявно (не через return ).
Про такие функции говорят, что они обладают сайд-эффектами, и в противоположность чистым функциям их называют грязными.
Cайд-эффектами называют неявные зависимости функции или неявные результаты её работы.
Звучит довольно просто, однако на практике в языках без явных ограничений на чистоту функции данное определение предстаёт не таким однозначным.
Сайд-эффект — что ты такое?
Первое и самое главное:
Сайд-эффект — это не первоклассный объект
Что это значит? Первоклассный объект (first-class object) — это сущность в языке программирования, которую:
Проще говоря, первоклассный объект можно легко представить в виде некоторого значения. Очевидно, что для сайд-эффектов это не так. Мы не можем просто взять и переписать функцию app в виде:
Сайд-эффекты зависят от/влияют на внешнее окружение
Это довольно очевидное свойство. Для того, чтобы корректно выполнить некоторый сайд-эффект, нам необходимо корректное окружение: для HTTP запроса нужна рабочая сеть, для запроса к DOM необходим сформированный DOM и так далее.
Сайд-эффекты лишают функции ссылочной прозрачности
Ссылочная прозрачность (referential transparency) — свойство функции, благодаря которому можно всегда и везде вместо результата работы функции подставить её вызов.
Функции с сайд-эффектами не обладают этим свойством — вызвав app два раза, мы получим совершенно другие результаты (будет два listener вместо одного, два HTTP запроса при клике вместо одного и так далее).
Сайд-эффекты изменяют свойства кода, в котором используются, до самой вершины стека вызовов
На самом деле, скорее всего, последние два свойства вытекают из первого — но это только догадка, и поэтому я решил вынести их в отдельные пункты.
Что всё это значит для нас?
Ну, окей, сайд-эффекты имеют какие-то свои специфичные свойства. Но что эти свойства означают для нас на практике?
Код с сайд-эффектами сложен для анализа (как человеком, так и машиной)
Для начала давайте посмотрим на код без сайд-эффектов — все функции в нём чистые.
Мы можем легко увидеть, какие значения от каких зависят, а какие не играют роли. К примеру, мы видим, что от a ничего не зависит и его вычисление можно смело удалить.
Более того, мы можем построить граф вычислений:
А теперь попробуем проделать то же самое с кодом, в котором, возможно, содержатся сайд-эффекты:
Это оказывает влияние на:
Также в случае кода с сайд-эффектами значительно усложняется рефакторинг. К примеру, удаление не использующегося кода:
Код с сайд-эффектами сложно переиспользовать
Это менее очевидное следствие из свойств сайд-эффектов. Давайте вновь взглянем на код, состоящий из чистых функций.
Мы написали функцию, которая считает длину и сумму массива:
Используя её, мы можем легко написать функцию, вычисляющую только длину списка:
Чистые функции крайне легко переиспользуются: даже если они делают что-то лишнее или что-то немного не так, мы всегда можем исправить это, просто добавив обёртку из ещё одной чистой функции.
Любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции.
Давайте посмотрим на функцию с сайд-эффектами, которая делает HTTP запрос и записывает результат в некий файл:
Теперь где-то в коде нам понадобилось отправлять тот же запрос, но не записывать его в файл.
Cкорее всего, мы добавим специальную опцию в sendRequestAndWriteFile :
То же самое для ситуации, когда нам захотелось отправлять запросы на другой URL:
Это заставляет нас вместо простого переиспользования добавлять множество опций в функцию, что очень сильно увеличивает цикломатическую сложность кода a.k.a complexity.
Количество вариантов выполнения растёт со скоростью 2^n: для функции всего с двумя булевыми опциями мы получаем уже 4 варианта исполнения, для трёх опций — уже 8 и так далее.
Cайд-эффекты сложно тестировать
С этим наверняка знакомы все. Сравните:
Выглядит немного сложнее, да? Но постойте, мы не проверили тот факт, что наша функция делает ровно один HTTP запрос. Исправим:
Зачем мы вообще пишем автоматизированные тесты? Для того, чтобы контролировать изменения кодовой базы. В случае изменения поведения кода мы сразу увидим, что старые тесты не пройдут. Дело в том, что при достаточно большой кодовой базе различные изменения могут конфликтовать между собой и «ломать» друг друга. Автоматические тесты защищают наши изменения от случайной поломки при каких-либо правках (это может быть банальный мерж конфликтов).
Давайте изменим тестируемые функции и посмотрим, что произойдёт в обоих случаях:
Тест, конечно же, упадёт — 4 не равно
Теперь давайте изменим remoteAdd :
Результат работы функции изменился — теперь она ещё и пишет в файл. Однако наш тест совершенно этого не заметил и продолжает проходить как ни в чём не бывало.
Так как функции с сайд-эффектами зависят от внешнего мира и влияют на него неявно, то, соответственно, чтобы корректно протестировать такую функцию, необходимо:
Очевидно, что сделать это полностью корректно, скорее всего, невозможно, так как количество типов сайд-эффектов в JS не ограничено.
Какие проблемы у подобного подхода:
Если бы мы хотели протестировать код с сайд-эффектами «честно», мы должны были написать что-то подобное:
Альтернативным способом решения проблемы является написание полностью интеграционных тестов с полноценным браузерным или серверным окружением. Помимо всё тех же проблем со сложностью создания и сравнения состояния окружения (к примеру, как сравнить весь DOM до некоторой операции и после?) добавляются ещё и следующие проблемы:
Cайд-эффекты непредсказуемы и не воспроизводимы
Всё течёт, всё меняется, никто не может дважды войти в один и тот же поток, и к смертной сущности никто не прикоснется дважды!
Из-за того, что внешний мир непредсказуем и постоянно изменяется, мы также не можем воспроизвести результаты вычислений, содержащих сайд-эффекты.
add(a, b) === add(a, b) будет всегда истинно в любых условиях и окружении. Мы можем легко воспроизвести результаты некоторой проблемы с продакшена, просто взяв, к примеру, входные данные с мониторинга и запустив вычисления с этими параметрами. Сайд-эффекты приводят к невоспроизводимым багам: чтобы понять, в чём была проблема, нам надо проанализировать не только наш код, но и состояние всего окружающего мира в тот момент. Это намного более трудоёмко, а порой и вообще невозможно.
Cайд-эффекты не типизируются
Одним из способов контроля кодовой базы и доказательства отсутствия нежелательного поведения программы является статическая типизация.
Очень много копий сломано вокруг того, нужна ли она вообще или нет.
Моё мнение простое: статическая типизация — это инструмент, незаменимый для написания некоторого типа ПО — такого, где очень много кода, много программистов, много связанных подсистем.
Однако вопрос не в этом, а в том, как на использование типизации влияют сайд-эффекты. Рассмотрим пример: предположим, мы имеем функцию, которая по описанию изменения как-то модифицирует DOM :
Сайд-эффекты за счет своей неявности не поддаются описанию типами, и тайп-чекер не может помочь найти проблемы с ними.
Возможным решением является использование имитации Higher-Kinded types для реализации типа Eff при помощи Flow :
В общем, решение не общее и не самое простое.
Усложнение интерактивной разработки кода с сайд-эффектами
Интерактивная разработка начинает набирать популярность. Практически все более-менее популярные языки имеют в стандартной поставке REPL (отдельно или в составе дебаггера). Современные браузеры вообще позволяют писать код прямо в них.
Появляются и отдельные IDE, нацеленные именно на интерактивную разработку. К примеру, Light table, позволяющая в реальном времени следить за результатами вычислений:
Главное преимущество интерактивной разработки — быстрая ответная реакция от только что написанного кода — в таком случае сводится на нет тем, что нам необходимо постоянно наблюдать состояние окружающего мира и периодически исправлять его. Например, восстанавливать удалённого юзера.
Для кода с сайд-эффектами сложно применить тестирование, основанное на проверке свойств
Тестирование, основанное на проверке свойств, или генеративное тестирование, или property-based тестирование — техника, позволяющая описывать свойства какой-то программной сущности (функции, к примеру) и проверять её при помощи генерации входных параметров.
Это очень мощная техника, которая позволяет доказать (с некоторой долей вероятности, конечно же) некоторые утверждения о программном коде. Она становится особенно важной в языках без сильной статической системы типов.
Но, как я отметил в предыдущей своей статье, крайне сложно определить какое-либо свойство для кода с сайд-эффектами — за счет их непредсказуемости.
Мелкие вредители, вредящие по-крупному
Сайд-эффекты — как гремлины, ломают все доступные программисту инструменты, до которых доберутся: типизация, тесты, интерактивные среды, статические анализаторы в IDE, код-ревью.
Но почему это всё действительно важно? Ну да, что-то стало сложнее сделать, но программисты привыкли к борьбе со сложностями. И в отдельных пунктах я приводил результаты такой борьбы — инструменты, которые призваны хоть как-то уменьшить негативное влияние сайд-эффектов.
Проблема в том, что сайд-эффекты не только усложняют написание и работу с самим кодом, но и «ломают» два базовых способа разработки ПО. И это уже реальная проблема.
Два сломанных способа разработки ПО
На самом высоком уровне, по большому счету, существует только два способа разработки. Всё остальное — либо их комбинации, либо производные.
«Сверху-вниз» a.k.a Нисходящий стиль a.k.a Top-Down
Определяем спецификацию самого верхнего уровня API — описываем входное и выходное воздействие:
Осталось придумать, как записывать спецификацию для описания входных и выходных данных:
В идеале она должна описывать все возможные входные воздействия и результаты довольно общим образом — тесты подходят не очень хорошо, так как они описывают отдельные кейсы вместо общего поведения системы.
Мы должны иметь возможность проверить, что разработанная нами программа соответствует изначальной спецификации, иначе при имплементации есть большой шанс получить значительное расхождение со спецификацией. Диаграммы и прочие способы, связанные с ИЗО, не дадут нам такой возможности.
Вы, наверно, уже догадались, что лучше всего здесь подойдёт хорошая система типов.
Люди иногда спрашивают: «Что служит аналогом UML для Haskell?». Когда меня впервые спросили об этом 10 лет назад, я подумал: «Ума не приложу. Может быть, нам стоит придумать свой UML». Сейчас я думаю: «Это просто типы!». Люди рисуют UML-диаграммы, чтобы понять общую схему программы. Именно этим занимаются программисты на функциональных языках и на Haskell, когда придумывают сигнатуры типов для модулей и функций в этих модулях.
Однако, как мы выяснили, без определённых уловок большая часть систем типов не способны работать с сайд-эффектами и уж точно не могут вывести типы таких эффектов из контекста. Можно было бы, конечно, заменить типы тестами (что, например, сделано во всем известном Test Driven Development), но, как мы уже увидели, тесты не очень хорошо подходят для этого из-за своей дискретной природы, к тому же они тоже страдают от сайд-эффектов.
Таким образом сайд-эффекты ломают первый базовый способ разработки ПО. Но, может, со вторым нам повезёт больше?
«Снизу-вверх» a.k.a Восходящий стиль a.k.a Bottom-Up
Мы можем пойти с другой стороны.
Уже по описанию задачи видно, что нам надо будет уметь выводить что-то на экран и надо уметь складывать. Мы не будем пытаться определить точные спецификации. Вместо этого просто напишем общие и минимально необходимые функции для этого. Больше всего эти функции будут похожи на отдельные небольшие библиотеки (очень малоспецифичные и очень переиспользуемые единицы), так как мы ещё не знаем, что за API нам придётся с их помощью строить.
Затем строим из этих функций API более высокого уровня:
Для такого итеративного процесса нам необходим инструмент, позволяющий легко экспериментировать с небольшими кусочками кода и иметь возможность быстро запустить отдельные функции на разных входных данных. При этом в процессе разработки нам не так важно зафиксировать некоторый результат и уметь его воспроизводить — вероятней всего, мы редко будем менять имплементацию уже написанного API. Тесты тут будут скорее мешать низкой скоростью ответной реакции и своей хрупкостью.
Однако, как мы помним, REPL теряет свое главное преимущество (быстрый отклик) при разработке кода с сайд-эффектами. Второй фундаментальный способ тоже не выдержал этой битвы.
Но ведь не весь наш код содержит сайд-эффекты? И, может, все эти неприятности касаются только тех участков, в которых мы их используем? Может, просто стараться использовать поменьше «грязных» функций и побольше «чистых»?
Лед-9 для программного кода
— Итак, в этом романе мир погибает потому, что во льду обнаружена молекула, которая при соприкосновении с водой превращает её в лед. А поскольку все воды мира связаны — пруд с ручьем, ручей с рекой, река с озером, озеро с океаном — таким образом, весь мир замерзает и погибает. И эта молекула называется «Лед-9».
Асинхронность и сайд-эффекты выглядят довольно связанными проблемами — решив только одну из них, вы не избавитесь от всех их недостатков, они лишь переместятся. С другой стороны, хорошее решение одной из этих проблем может помочь решить другую. В дальнейшем мы увидим, что это не случайно и на самом деле оба этих явления представляют собой лишь частные случаи более фундаментальной проблемы отсутствия общего способа абстракции control-flow программы и выражения его first-class значениями.
Но самое ужасное в таких функциях было то, что они заражали весь код, в котором использовались. Обычная функция при использовании в ней функции с коллбэком переставала возвращать результат через return и начинала прокидывать его в коллбэк — и, в свою очередь, сама становилась «ядом» для использующего её кода.
Появилась даже метафора двухцветного языка:
Все функции в языке делятся на «красные» и «синие». И чтобы вызвать «красную» функцию в «синей», нам необходимо перекрасить «синюю» функцию в красный цвет.
Поэтому всё то же самое применимо и к ним:
Рассмотрим пример. Допустим, у нас есть такая иерархия вызовов:
Все вызовы чистые и предсказуемые. С ними нет никаких проблем.
Но неожиданно нам понадобилось кэшировать результаты вычисления функции calcForItem в localStorage :
И наша иерархия стала выглядеть так (красным отмечены функции с сайд-эффектами ):
Изменив код всего одной функции, мы изменили свойства (в плане тестируемости, надёжности, композируемости) для всего стека вызовов.
В некотором смысле мы теряем контроль над своим кодом. Его поведение может измениться, хотя он сам останется прежним — просто API, на котором основан наш код, внезапно станет «грязным» и «заразит» его.
In Soviet Russia side-effects control you!
Если мы не контролируем ПО, то оно начинает контролировать нас (разработчиков). В результате всего вышесказанного у нас получается код, который:
нельзя полноценно протестировать, да и, чтобы протестировать хоть как-то, нужно приложить много усилий — из-за этого мы пишем недостаточно тестов. Проверьте свое покрытие кода с сайд-эффектами и кода, работающего только с данными — скорее всего, во втором случае цифра будет намного выше;
нельзя верифицировать или попробовать доказать его свойства при помощи property-based тестов — у большей его части просто нет каких-либо предсказуемых свойств;
неудобен для работы в интерактивной среде ( REPL ), потому что там не получится работать с DOM-элементами или безопасно послать HTTP-запрос;
практически не поддается рефакторингу, так как сайд-эффекты создают неявные зависимости;
непредсказуем — невозможно создать надёжные инструменты воспроизведения поведения приложения. Обычно не является проблемой по результатам мониторинга понять, что произошо. Но вот почему так произошло — может быть совершенно неясно, так как части приложения влияют друг на друга неявно;
очень тяжело переиспользуется. Иногда без внесения правок в исходники нельзя переиспользовать то или иное решение. Поэтому наученные горьким опытом разработчики зачастую стремятся не переиспользовать крупные части своего приложения (не говоря уже о больших и сложных сторонних компонентах), так как не ясно, возможно ли будет избавиться от некоторых нежелательных действий, если они вдруг станут не нужны.
При этом разработчики сами по себе не хотят писать такой код. Почти любой разработчик скажет, что код должен быть хорошо тестируемым, переиспользуемым и так далее. Нас учат этому с самого начала работы в индустрии.
Однако сайд-эффекты в нашем коде вынуждают нас частично отказаться от всех хороших практик и практически всех доступных программисту инструментов. Софт, который контролирует людей? Я знаю, кому это точно понравится:
При этом мы не пытаемся избавиться от этого контроля и воспринимаем его как что-то само собой разумеющееся. Все эти проблемы давно известны, но мы не пытаемся воздействовать на их причину, а только исправляем отдельные симптомы:
I have a dream.
Попытки решать фундаментальную проблему, борясь только с её отдельными проявлениями, вряд ли могут увенчаться успехом.
Нам необходимо фундаментальное решение проблемы сайд-эффектов в нашем коде. Причём оно должно было максимально общим — не привязанным к какому-то фреймворку или инфраструктуре и не навязывающим какую-либо конкретную архитектуру. Оно должно решать ровно одну проблему и делать это хорошо.
Но как мы можем создать такое решение?
Но мы можем полностью отделить логику нашего приложения от сайд-эффектов.
Всё наше приложение станет полностью чистой функцией — будет явно принимать все входящие воздействия и явно возвращать выходные. А сайд-эффекты будут исполняться отдельно от основного приложения.
Существует минимум 3 способа сделать это, и все они основаны на теоретических основах Computer Science, разработанных около 40 лет назад.
Все эти способы объединяет то, что они созданы для абстракции control-flow программы. Control-flow — это скелет нашей программы, её базис, поэтому эти способы возникают при решении большей части проблем в Computer Science — не только при решении проблемы сайд-эффектов. Однако это тема для следующей статьи.
Цикл for хорошо послужил нам, но он устарел и должен уступить место более новым, функциональным техникам программирования.
К счастью, этот факт не требует от вас быть мастером функционального программирования, более того, это то, что вы можете использовать в своих текущих проектах прямо сегодня!
Так в чем проблема цикла for в JavaScript?
Дизайн цикла for подталкивает к мутациям состояния (англ. mutation of state — изменение состояния — прим. переводчика) и применению сайд эффектов (англ. side effects — побочные эффекты — прим. переводчика), которые являются потенциальными источниками багов и непредсказуемого поведения кода.
Все мы слышали, что глобальное состояние — это плохо, и что мы должны избегать его. Однако, локальное состояние разделяет те же проблемы что и глобальное, мы просто не сталкиваемся с ними так часто, ведь они проявляются в меньших масштабах. Фактически, мы никогда не решали проблему, а просто сводили ее к минимуму.
Однажды, используя мутабельное состояние (англ. mutable state — изменяемое состояние — прим. переводчика), значение случайной переменной изменится по неизвестной причине, и вы потратите часы на отладку и поиск причины изменения. У меня волосы на голове встают дыбом, только от одной мысли об этом.
Я бы хотел немного поговорить о сайд эффектах. Эти слова даже звучат ужасно, сайд эффекты. Дрянь. Вы хотите чтобы в ваших программах были сайд эффекты? Нет, я не хочу сайд эффектов в моих программах!
Но что такое сайд эффекты?
Считается, что у функции есть сайд эффекты если она модифицирует что-то за пределами своей области видимости. Это может быть изменение переменной, пользовательский ввод, запрос к api, запись данных на диск, лог в консоль и т.д.
Сайд эффекты — действительно мощный инструмент, но с большой силой приходит большая ответственность.
Сайд эффекты, по возможности, должны быть устранены или хотя бы инкапсулированы так, чтобы мы могли их контролировать. Функции с сайд эффектами тяжелее читать и тестировать, избегайте их всегда, когда это возможно. К счастью, в рамках данной статьи, мы не будем беспокоиться о побочных эффектах.
Я собираюсь отрефакторить этот код шаг за шагом, чтобы вы смогли пронаблюдать как легко превратить ваш собственный код в нечто более прекрасное.
Во-первых, я извлеку условное выражение в отдельную функцию:
Выносить условия — это в целом хорошая практика. Изменение фильтрации с “меньше чем 7 месяцев” на “является ли котенком” — большой шаг вперед. Теперь код передает наши намерения гораздо лучше. Почему мы берем котов до 7 месяцев? Не совсем понятно. Мы хотим найти котят, так пусть код говорит об этом!
Другая польза в том, что isKitten теперь можно переиспользовать, а все мы знаем, переиспользование кода всегда должно быть нашей целью.
Следующее изменение — извлечь преобразование (или отображение) кота его в имя. Это изменение будет понятнее позднее, а сейчас просто доверьтесь мне.
Код отдающий предпочтение const перед var и let выглядит чертовски привлекательно
Конечно, мы могли использовать const с самого начала, так как он не делает сам объект иммутабельным (об этом больше в другой раз), но это придуманный пример, не наседайте!
И последнее изменение, я бы предложил также извлечь фильтрацию и отображение в функцию (для полного переиспользования кода).
Домашнее задание
Изучить извлечение методов filter и map из их объектов. Задание со звездочкой: исследовать композицию функций.
Что насчет break
Многие из вас спрашивали, “Что насчет break ”, посмотрите часть вторую серии “Переосмысление JavaScript: break это GOTO циклов”.
Заключение
Для вас это мелочь, но меня очень радует когда кто-то подписывается на меня на медиуме или в твиттере (@joelnet), а если вы считаете мой рассказ бесполезным, то расскажите об этом в комментариях.