В сложных основах кода сложные взаимодействия побочных эффектов - это самое трудное, о чем я нахожу рассуждать. Я могу говорить только лично, учитывая то, как работает мой мозг. Побочные эффекты и постоянные состояния, изменяющиеся входные данные и т. Д. Заставляют меня думать о том, «когда» и «где» происходят вещи, чтобы рассуждать о правильности, а не только о том, «что» происходит в каждой отдельной функции.
Я не могу просто сосредоточиться на "что". После тщательного тестирования функции, вызывающей побочные эффекты, я не могу сделать вывод о том, что она будет распространять атмосферу надежности по всему коду, использующему ее, поскольку вызывающие могут все еще использовать ее неправильно, вызывая ее в неправильное время, из неправильного потока, из неправильного заказ. Между тем, функцию, которая не вызывает побочных эффектов и просто возвращает новый вывод при условии ввода (не касаясь ввода), почти невозможно использовать таким способом.
Но я прагматичный тип, я думаю, или, по крайней мере, пытаюсь быть таковым, и я не думаю, что мы обязательно должны искоренять все побочные эффекты до минимума, чтобы рассуждать о правильности нашего кода (по крайней мере, Мне было бы очень трудно это сделать в таких языках, как C). Мне очень трудно рассуждать о правильности, когда у нас есть комбинация сложных потоков управления и побочных эффектов.
Сложные управляющие потоки для меня - это графоподобные по своей природе, часто рекурсивные или рекурсивные (например, очереди событий, которые не вызывают напрямую рекурсивные вызовы, но имеют «рекурсивный» характер), возможно, делают что-то в процессе обхода фактической структуры связанного графа или обработки неоднородной очереди событий, которая содержит эклектическую смесь событий для обработки, которая приводит нас ко всем видам различных частей кодовой базы и вызывает различные побочные эффекты. Если бы вы попытались нарисовать все места, которые в конечном итоге окажутся в коде, он будет напоминать сложный граф и потенциально с узлами в графе, которых вы никогда не ожидали, были бы там в данный момент, и, учитывая, что все они вызывая побочные эффекты,
Функциональные языки могут иметь чрезвычайно сложные и рекурсивные потоки управления, но результат так легко понять с точки зрения корректности, потому что в этом процессе происходят не все виды эклектических побочных эффектов. Только когда сложные потоки управления встречают эклектичные побочные эффекты, я нахожу головокружительным пытаться понять все, что происходит, и всегда ли это будет делать правильно.
Поэтому, когда у меня есть такие случаи, мне часто бывает очень трудно, если не невозможно, чувствовать себя очень уверенным в правильности такого кода, не говоря уже о том, что я могу внести изменения в такой код, не наткнувшись на что-то неожиданное. Таким образом, для меня решение состоит в том, чтобы либо упростить поток управления, либо минимизировать / унифицировать побочные эффекты (под объединением я подразумеваю, как вызывающий побочный эффект только одного типа для многих вещей в течение определенной фазы в системе, а не для двух или трех или дюжина). Мне нужно, чтобы произошло одно из этих двух событий, чтобы мой простой мозг чувствовал себя уверенно относительно правильности существующего кода и правильности внесенных мною изменений. Довольно легко быть уверенным в правильности кода, вводящего побочные эффекты, если побочные эффекты единообразны и просты вместе с потоком управления, например, так:
for each pixel in an image:
make it red
Правильность такого кода довольно легко рассуждать, но в основном потому, что побочные эффекты настолько однородны, а поток управления настолько прост. Но допустим, у нас был такой код:
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
Тогда это смехотворно упрощенный псевдокод, который обычно включает в себя гораздо больше функций и вложенных циклов, а также гораздо больше вещей, которые необходимо выполнить (обновление нескольких карт текстур, веса костей, состояний выделения и т. Д.), Но даже псевдокод делает его настолько трудным Причина правильности из-за взаимодействия сложного графоподобного потока управления и происходящих побочных эффектов. Таким образом, одна стратегия, упрощающая это, заключается в том, чтобы отложить обработку и сосредоточиться только на одном типе побочного эффекта за раз:
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
... что-то на этот счет как одна итерация упрощения. Это означает, что мы пропускаем данные несколько раз, что, безусловно, влечет за собой вычислительные затраты, но мы часто обнаруживаем, что можем упростить многопоточность такого получающегося в результате кода, теперь, когда побочные эффекты и потоки управления приобрели такую однородную и более простую природу. Кроме того, каждый цикл можно сделать более удобным для кэширования, чем обход связанного графа и вызывающий побочные эффекты по ходу дела (например: используйте параллельный бит, установленный для отметки того, что необходимо пройти, чтобы мы могли затем выполнять отсроченные проходы в отсортированном последовательном порядке используя битовые маски и FFS). Но самое главное, я считаю, что вторую версию гораздо проще рассуждать с точки зрения правильности, а также изменений, не вызывая ошибок. Так что'
И, в конце концов, нам нужно, чтобы побочные эффекты возникали в какой-то момент, иначе у нас просто были бы функции, которые выводили данные, и некуда было бы идти. Часто нам нужно что-то записать в файл, отобразить что-то на экране, отправить данные через сокет, что-то в этом роде, и все эти вещи являются побочными эффектами. Но мы определенно можем уменьшить количество лишних побочных эффектов, которые продолжаются, а также уменьшить количество побочных эффектов, происходящих, когда потоки управления очень сложны, и я думаю, что было бы намного легче избежать ошибок, если бы мы это сделали.