Чистые и эффективные функции: Эффекты

ВременнАя связность

Эффекты могут обладать неявной временнОй связностью (temporal coupling) между собой. Это не в том смысле, что связность пропадает со временем, а в том смысле что, результат выполнения двух эффектов зависит от очерёдности их исполнения. Например, рассмотрим такую программу:

val buffer = StringBuilder()
buffer.append("a")
buffer.deleteCharAt(0)

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

Чистая же версия этого кода такая:

val emptyString = ""
val aString = emptyString + "a"
val clearedString = aString.substring(1, aString.length)

И здесь компилятор махом вам даст по рукам, если вы случайно поменяете эти строки руками. В этой версии связь вызовов очевидна.

Речь тут идёт не только о памяти - работа с любым изменяемым хранилищем вроде диска, СУБД, REST API и т.п., создаёт временнУю связность между кусками кода, которые пишут и читают это хранилище.

Нелокальность рассуждений

Из-за временнОй связности теряется локальность рассуждений о программе.

Если вы работаете с кодом ``неосознанного'' проекта, то у вас объекты будут мутабельными. И вы не можете свободно вызывать какие-либо методы передавая свой объект в качестве параметра, потому как в таком проекте с высокой долей вероятности вызываемой код так или иначе изменит ваш объект и далеко не факт, что так, как вам надо, а не иначе.

В результате передавая объект в чужой метод вы вынуждены ``покинуть'' метод над которым работаете, и пройтись по стэку вызовов, чтобы удостовериться, что там никто вам не изгадит ваш объект. И дай вам бог, чтобы на вашем пути не встретились _{драконы} полиморфные и рефлексивные вызовы:) Наконец, если сейчас передача объекта безопасна, то не значит что завтра ваш коллега или вы сами не подложите себе свинью, в виде неожиданной мутации.

Регрессии

Но положа руку на сердце, вы меняя код задумываетесь о том, как эти изменения повлияют на порядок эффектов, на какое состояние эти эффекты направлены, и какие ещё эффекты направлены на это состояние? Прям каждый раз и прям тщательно всё изучая? Я - нет.

В итоге я регулярно меняя одно место, ломаю другое. Это ведёт к страху рефакторинга. Это ведёт к загниваюнию кодовой базы и превращению её в Big Ball of Mud.

Тестирование

С тестированием изменяемых объектов особых проблем не припоминаю. Ну ток что в комплекте с изменяемыми объектами зачастую идёт только конструктор без параметров и пачка сеттеров - это неудобно, но можно полечить просто добавив конструктор.

А вот тестирование ввода-вывода - это да, беда. Тестировать ио больно потому что такие тесты: 1. могут потребовать запуска внешнего сервиса (СУБД, например) 2. как минимум на порядок, а то и пять медленнее тестов только в памяти 3. намного менее стабильны 4. вообще непонятно как писать для устройств отличных от диска и сетевой карты

Отсюда началась движуха про пирамиду тестов в которой львиная доля тестов должна быть юнит-тестами и про ``давайте замочим всю систему''.

Только оби этих практики ведут к тестам, которые ломаются при любом мало мальском рефакторинге. Это ведёт к страху рефакторинга. Это ведёт к загниванию кодовой базы и преваращению её в Big Ball of Mud (ссылка выше:) ).

И не понятно как это поможет ловить баги в системах ориентированных на ввод-вывод, где из логики ток тривиальная валидация отданая на откуп либе.

Но чёт я отвлёкся от темы, про тесты будет своя серия постов.

Производительность

Опять же это касается только эффектов ио, т.к. они существенно медленнее работы с памятью.

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

Или словить печально известную проблему N+1 и даже не заметить этого, пока количество таких проблем не положит систему намертво.

Или случайно через полиморфный вызов засунуть сетевой вызов внутрь транзакции БД. После того как уже захватили пачку локов.

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

Конкурентное программирование

Если у вас есть эффекты, то их надо упорядочивать, а для этого надо идти в конкурентное программирование. А это очень сложно, поверьте мне на слово, если ещё сами не убедились в этом на своём опыте:)

Чистый же код можно спокойно параллелить как угодно и вообще не греть голову об этом.

Кэширование

Ну и опять же с эффектами появляется одна из двух самых сложных задач в программировании. После конкурентности, конечно :)

В итоге мы пришли к Дилемме Эффектов - без эффектов никак, а с ними ещё хуже. Как же быть? Для начала, надо присмотреться к эффектам поближе.