副作用是好事吗？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

3 年前已关闭。

Answer 1

没有副作用，就无法执行I/O操作； 所以你无法做出有用的应用程序。

Answer 2

这句话真的让我笑了。 也就是说，我发现副作用最小化可以真正转化为更容易推理和维护的代码。 然而，我没有足够的时间去探索函数式编程，正如我所希望的那样。

在使用围绕副作用的面向对象和过程语言时，我看待它的方式是包含和隔离副作用。

作为一个基本示例，视频游戏具有将图形渲染到屏幕上的必要副作用。 然而，关于副作用，这里有两种不同的设计路径。

人们试图通过使渲染器变得非常抽象并基本上告诉要渲染什么来最小化和放松耦合。 然后，系统的其他部分告诉渲染器要绘制什么，这可能是一批基元，例如带有投影和模型视图矩阵的三角形和点，或者可能是更高级别的东西，例如抽象模型、相机、灯光和粒子。 不管怎样，这样的设计围绕着许多导致外部副作用的事情，因为代码库的许多部分可能会将更改推送到渲染器（无论多么抽象或间接，最终效果仍然是这样一个整体中的一大堆事情）系统触发外部渲染副作用）。

另一种方法是遏制/隔离这些副作用。 渲染器不是被告知要渲染什么，而是与游戏世界耦合（尽管这可能只是一些基本的抽象，并且可能访问场景图）。 现在，它可以自行访问场景（只读访问），并查看场景并找出要使用更多拉式设计渲染的内容。 这导致渲染器与游戏世界的耦合程度更高，但这也意味着与屏幕输出相关的副作用现在完全包含在渲染器内。

后一种设计包含或隔离副作用，而且我发现这种类型的设计更容易维护和保持正确。 它仍然会产生副作用，但与将图形输出到屏幕相关的所有副作用现在完全包含在渲染器中。 如果那里出现问题，您知道错误将出现在渲染器代码中，而不是外部滥用它并告诉它做错误的事情的结果。

正因为如此，当谈到耦合时，我总是发现更理想的是在导致外部副作用的事物中最大化传出（传出）耦合并最小化传入（传入）耦合。 无论抽象如何，这都适用。 在副作用的上下文中，只要就将要发生的副作用进行通信，对 IRenderer 的依赖仍然是对具体 Renderer 的依赖。 就将发生什么副作用而言，抽象并没有什么区别。

渲染器应该依赖于世界的其他部分，以便它可以将这些副作用完全隔离到屏幕上； 世界其他地方不应该依赖渲染器。 文件保护程序也是如此。 外界不应该告诉文件保存程序要保存什么。 它应该审视周围的世界，并自行找出要拯救的内容。 这就是寻求隔离和遏制副作用的设计路径； 它往往更多地是基于拉的而不是基于推的。 如果您绘制出依赖关系，结果往往会引入更多的耦合（尽管可能是松散的），因为保存程序可能需要与它甚至不感兴趣保存的事物耦合，或者渲染器可能需要对事物的只读访问权限它甚至对渲染不感兴趣来发现它对渲染感兴趣的东西。

然而，最终结果是依赖关系远离副作用，而不是流向副作用。 当我们有一个具有许多依赖项来推动外部副作用的系统时，我总是发现这些是最难推理的，因为系统的许多部分可能会改变外部状态，以至于不仅很难弄清楚是什么将会发生，但也有何时和何处。 因此，纠正/防止该问题的最直接方法是寻求使依赖项远离副作用，而不是流向副作用。

不管怎样，我发现支持这些类型的设计是一种实用的方法，可以帮助避免错误，也可以帮助检测和隔离它们（当它们存在时），使它们更容易重现和纠正。

我发现的另一个有用的策略是使系统的任何给定循环/阶段的副作用更加均匀。 例如，我发现，在这种情况下，如果您执行三个同构循环，而不是执行一个从某些内容中删除关联数据、取消链接，然后删除它的循环，会容易得多。 第一个同构循环可以删除关联的数据。 第二个同构环路可以使节点脱链。 第三个同质循环可以将其从系统的其余部分中删除。 这是在较低级别的注释上，与实现相关而不是与设计相关，但我经常发现结果更容易推理、维护，甚至优化（更容易并行化，例如，并且具有改进的引用局部性）——你采取这些非同质循环触发多种不同类型的副作用，并将它们分解为多个同质循环，每个循环仅触发一种统一的副作用。

Answer 3

由于您的程序必须具有副作用才能产生任何输出或有趣的效果（除了加热 CPU 之外），因此问题在于应在程序中的何处触发这些副作用。 只有当它们以您意想不到的方式隐藏时，它们才会变得有害。

根据经验，将纯方法和具有副作用的方法分开。 将某些内容打印到控制台的方法应该只执行此操作，而不是计算您可能想在其他地方使用的一些有趣的值。

Answer 4

嗯，一方面，使用副作用进行编程要容易得多、直观得多。 对于很多人来说，函数式编程很难理解——找到一个在 Ocaml 中教授/助教过的人，你可能会听到各种各样关于人们完全无法理解它的故事。 如果没有人能够真正遵循它，那么设计精美、无副作用的功能代码有什么好处呢？ 雇用人员来完成您的软件变得相当困难。

至少这是争论的一方面。 有很多原因让很多人不得不学习函数式风格、无副作用的代码。 我想到了多线程。

Answer 5

我认为平衡的答案是，人们应该寻找机会最小化或避免副作用，或者考虑它们在哪里，并寻找机会将它们移到其他地方以使代码更容易理解。

这里我给出了一些代码的两个版本。 当我开始寻找机会将看起来像第一个版本的代码更改为看起来像第二个版本的代码时，我的生活变得更好：

它可能有一个具有属性 first, secondary,third 和方法 first_method、second_method、third_method 类似

def first_method(self):
    # calculate and set self.first

def second_method(self):
    # use self.first to calculate and set self.second

def third_method(self):
    # use self.first and self.second to calculate self.third

，然后是更高级别的方法：

def method(self):
    self.first_method()
    self.second_method()
    self.third_method()

现在想象这些名称不以“first”、“second”、“third”为前缀，而是描述这些方法的作用，并且程序比较复杂。 这是我在探索滥用副作用的代码时经常遇到的问题。 我必须不断地查看函数的实现，以了解调用它们的效果以及它们如何协同工作。

现在，不用对“副作用是邪恶的”东西发疯，我们仍然可以从避免副作用的愿望中受益：

def first_func():
    # calculate the first thing and return it

def second_func(first_thing):
    # use first_thing to calculate second_thing and return it

def third_func(first_thing, second_thing):
    # use first_thing and second_thing to calculate third_thing and return it

并且更高级别的方法可能看起来像

def method(self):
    self.first_thing = first_func()
    self.second_thing = second_func(self.first_thing)
    self.third_thing = third_func(self.first_thing, self.second_thing)

我们仍然有副作用，方法设置属性但是当我们尝试了解组成它的函数如何协同工作时，很明显您必须按此顺序调用它们，并且每个函数需要什么来完成其工作也很清楚。

另外，在第一个版本中，当查看方法的实现时，谁知道每个函数会更改对象的其他哪些属性。 当查看第二个版本时，所有人都可以清楚地看到调用 method 仅更改了三个属性，而无需查看函数的实现。

这个例子可能看起来很简单，因为我为了这个解释而凭空制作了它。 我尽力传达了一些我在尝试理解编写的代码时遇到的实际问题，这些代码对副作用没有一丝蔑视。 像第一个版本一样操作的现实世界代码比像第二个版本一样操作的现实世界代码更难理解。

正如其他人所说，我对副作用的看法是，值得问自己副作用是否可以移动或避免，这样做通常会导致代码更容易理解。

Answer 6

我经常看到一个关于 SO 的问题，这迫使我花半个小时编辑一篇非常糟糕的维基百科文章。 这篇文章现在只是中等程度的糟糕。 在与你的问题有关的部分，我写道：

在计算机科学中，如果函数或表达式除了产生值之外，还修改某些状态或具有可观察的值，则称该函数或表达式具有副作用与调用函数或外部世界的交互。 例如，函数可能会修改全局或静态变量、修改其参数之一、引发异常、将数据写入显示器或文件、读取数据、调用其他副作用函数或发射导弹。 在存在副作用的情况下，程序的行为取决于过去的历史记录； 也就是说，评估的顺序很重要。 因为理解一个有效的程序需要考虑所有可能的历史，所以副作用通常会使程序更难理解。

副作用对于程序与外界（人、文件系统、网络上的其他计算机）交互至关重要。 但副作用的使用程度取决于编程范例。 命令式编程因不受控制、滥用副作用而闻名。 在函数式编程中，很少使用副作用。 Standard ML 和Scheme 等函数式语言并不限制副作用，但程序员通常会避免副作用。 函数式语言 Haskell 通过静态类型系统来限制副作用； 只有产生 IO 类型结果的函数才会有副作用。

Answer 7

副作用是一种不可避免的罪恶，人们应该设法将其最小化/局部化。

该线程上的其他评论说，无效果编程有时并不那么直观，但我认为人们所认为的“直观”很大程度上是他们先前经验的结果，并且大多数人的经验都具有很强的必要性偏见。 主流工具每天都变得越来越实用，因为人们发现，由于单独组件的可能性较小，无效果编程会导致更少的错误（尽管不可否认，有时会出现新的/不同类别的错误）通过效果进行交互。

几乎没有人提到性能，并且无效果编程的性能通常比有效编程的性能更差，因为计算机是冯诺依曼机器，旨在与效果良好配合（而不是设计与效果良好配合）拉姆达）。 现在我们正处于多核革命之中，这可能会改变游戏规则，因为人们发现他们需要利用核心来获得性能，而并行化有时需要火箭科学家才能有效地获得正确的结果，当你没有效果时，很容易做到正确。

Answer 8

在冯诺依曼机器中，副作用是使机器工作的因素。 本质上，无论您如何编写程序，它都需要产生副作用才能工作（在低级别视图中）。

无副作用编程意味着抽象出副作用，以便您可以从总体上考虑问题，而不必担心机器的当前状态，并减少程序不同模块（无论是过程、类还是其他模块）之间的依赖关系。 通过这样做，您将使您的程序更具可重用性（因为模块不依赖于特定状态来工作）。

所以，是的，无副作用的程序是一件好事，但副作用在某种程度上是不可避免的（所以它们不能被视为“坏”）。

Answer 9

优点：

• 最终，副作用就是你想要实现的目标。
• 对于与外界交互的代码来说，副作用是很自然的。
• 它们使许多算法变得简单。
• 为了避免使用副作用，您需要通过递归来实现循环，因此您的语言实现需要尾部调用优化。

缺点：

• 纯代码很容易并行化。
• 副作用会使代码变得复杂。
• 纯代码更容易证明正确性。

比如Haskell，一开始看起来很优雅，但后来你需要开始和外面的世界玩，就不再那么有趣了。 （Haskell 将状态作为函数参数移动，并将其隐藏到称为 Monad 的东西中，这使您能够以命令式的类似风格进行编写。）

Answer 10

副作用就像任何其他武器一样。 毫无疑问，它们很有用，但如果处理不当，可能会非常危险。

就像武器一样，你会产生各种不同种类、不同程度的杀伤力的副作用。

在 C++ 中，由于指针，副作用是完全不受限制的。 如果变量被声明为“私有”，您仍然可以使用指针技巧访问或更改它。 您甚至可以更改不在范围内的变量，例如调用函数的参数和局部变量。 在操作系统（mmap）的帮助下，您甚至可以在运行时修改程序的机器代码！ 当你用 C++ 这样的语言编写时，你就被提升到了位神（Bit God）的地位，成为你进程中所有内存的主人。 编译器对您的代码进行的所有优化都是在您不滥用权力的假设下进行的。

在Java中，你的能力受到更多限制。 作用域中的所有变量都在您的控制之下，包括不同线程共享的变量，但您必须始终遵守类型系统。 尽管如此，由于您可以使用操作系统的子集以及静态字段的存在，您的代码可能会产生非本地效果。 如果一个单独的线程以某种方式关闭 System.out，这看起来就像魔术一样。 它将是魔法：有副作用的魔法。

Haskell（尽管宣传是纯粹的）有 IO monad，它要求你在类型系统中注册所有的副作用。 将你的代码包装在 IO monad 中就像手枪的 3 天等待期：你仍然可以炸掉自己的脚，但除非你得到政府的同意。 还有 unsafePerformIO 及其同类，它们是 Haskell IO 的黑市，给你带来“不问任何问题”的副作用。

Miranda 是 Haskell 的前身，是在 monad 流行之前创建的纯函数式语言。 Miranda（据我所知……如果我错了，请用 Lambda 微积分代替）根本没有 IO 原语。 唯一完成的 IO 是编译程序（输入）、运行程序并打印结果（输出）。 在这里，你拥有完全的纯洁。 执行顺序完全无关。 所有“效果”对于声明它们的函数来说都是局部的，这意味着代码的两个不相交部分永远不会互相影响。 这是一个乌托邦（对于数学家来说）。 或者相当于 distpia。 这很无聊。 什么也没有发生。 您无法为其编写服务器。 你不能在里面写操作系统。 你不能在里面写SNAKE或Tetris。 每个人都只是坐在旁边看着数学。

Answer 11

如果没有副作用，您就无法做某些事情。 一个例子是 I/O，因为根据定义，使消息出现在屏幕上是一种副作用。 这就是为什么函数式编程的目标是最小化副作用，而不是完全消除副作用。

抛开这一点不谈，在某些情况下，最大限度地减少副作用与其他目标（例如速度或内存效率）发生冲突。 其他时候，您的问题已经有了一个与变异状态的想法非常吻合的概念模型，与现有模型作斗争可能会浪费精力和精力。

Answer 12

确实，正如这里有些人提到的，如果没有副作用，就无法做出有用的应用程序。 但由此可见，以不受控制的方式使用副作用并不是一件好事。

考虑以下类比：具有没有分支指令的指令集的处理器绝对毫无价值。 然而，这并不意味着程序员必须一直使用goto。 相反，事实证明，结构化编程和后来的 OOP 语言（例如 Java）甚至可以不需要 goto 语句，而且没有人错过它。

（可以肯定的是，Java 中仍然有 goto - 现在称为 break、continue 和 throw。）

Answer 13

副作用对于大多数应用的重要部分来说是必不可少的。
纯函数有很多优点。 它们更容易思考，因为您不必担心前置条件和后置条件。 由于它们不改变状态，因此更容易并行化，随着处理器数量的增加，这将变得非常重要。

副作用是不可避免的。 只要它们比更复杂但纯粹的解决方案是更好的选择，就应该使用它们。 纯函数也是如此。 有时，使用功能性解决方案可以更好地解决问题。

一切都很好 =) 您应该根据要解决的问题使用不同的范例。