代码气味：死亡的副作用

经过一段时间的开发，可以肯定的是，您将永远后悔自己编写的代码。

我的最后一个遗憾来自副作用 ，我习惯于向某种方法发送一些对象引用，并通过引用来更新其内容，这种情况每天都非常普遍。

有了这样的代码，它很容易搞砸，并不断增加副作用，问题是您的代码变成了野马，您将永远不知道他的去向。 像这个“ setPet”方法调用一样，乍一看似乎没有什么害处，但是想象一下在成千上万行的代码中，该代码中的错误将是无处可寻的。

我们在此代码中还可以注意到的另一件事是方法签名，这是一个谎言！ 我们怎么知道他要从某些服务中获取数据？ 即使我们在签名中加上每个小小的副作用的名称，一眼就能看到200多个字符。

但是我想从我的方法中提取这种逻辑，以便他更易读！

我相信这一点，可以从我的代码中提取方法，并通过漫长的副作用来发送类的引用，从而满足我理想的干净代码，例如以下代码：

当您阅读唯一的公共方法“ insert（）”时，它似乎很容易理解并且很简单，但是这里有很多黑魔法。 以“ populatePersonFamily（） ”方法为例，它设置了对象的民事状态属性，但是它从未在任何地方声明，请想象如果前端想要更改此值，则必须调试整个过程，直到发现这个小把戏！

我从中学到的另一个教训是：如果我永远不会重复使用这种方法，为什么还要创建一种新方法来隔离某些逻辑呢？ 不要误会我的意思，我并不是说要开始使用五百行的方法！ 一切都与设计模式和职责有关 。

我的代码的问题是只在S英格尔- [R esponsibility P AGC软件的误解，为什么验证Person对象的服务，如果它是一个前端规则？ 为什么Person服务知道如何设置Pet对象并映射模型的值？ 所有这些都是另一天的主题，但是您明白了。

副作用就像在学校里一个假朋友，您认为他一直在帮助您，直到您需要他的帮助来解决某些问题为止。 很难跟踪一些错误，很难知道新功能对与引用配合使用的方法的影响，甚至更难以重构以这种方式使用的方法。

From: https://hackernoon.com/code-smell-side-effects-of-death-31c052327b8b