У складних кодових базах складні взаємодії побічних ефектів - це найскладніше, про що я можу пояснити. Я можу говорити лише особисто, враховуючи, як працює мій мозок. Побічні ефекти та стійкі стани, мутація входів і так далі змушують мене думати про те, "коли" і "де", що відбувається, щоб міркувати про правильність, а не лише про те, що відбувається в кожній окремій функції.
Я не можу просто зосередитись на "що". Я не можу зробити висновок після ретельного тестування функції, яка спричиняє побічні ефекти, що вона поширює ефір надійності по всьому коду, використовуючи її, оскільки абоненти можуть все-таки неправомірно використовувати її, називаючи її в неправильний час, з неправильної нитки, в неправильній замовлення. Тим часом функцію, яка не викликає побічних ефектів і просто повертає новий вихід із поданим входом (не торкаючись введення), в такий спосіб неправильно використати таким чином.
Але я прагматичний тип, я думаю, або, принаймні, намагаюся бути таким, і я не думаю, що нам обов'язково потрібно видаляти всі побічні ефекти до найменшого мінімуму, щоб міркувати про правильність нашого коду (принаймні Мені це було б важко зробити на таких мовах, як 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). Але найголовніше, що я вважаю другу версію набагато простішою міркуванням з точки зору правильності, а також зміни, не викликаючи помилок. Так що '
Зрештою, нам потрібні побічні ефекти в якийсь момент, інакше ми просто матимемо функції, які виводять дані нікуди. Часто нам потрібно щось записати у файл, щось вивести на екран, передати дані через сокет, щось подібне, і все це є побічними ефектами. Але ми, безумовно, можемо зменшити кількість зайвих побічних ефектів, які продовжуються, а також зменшити кількість побічних ефектів, що виникають, коли контрольні потоки дуже складні, і я думаю, що було б набагато простіше уникнути помилок, якби ми це зробили.