代码气味:死亡的副作用

代码气味:死亡的副作用

原文：https://medium.com/hackernoon/code-smell-side-effects-of-death-31c052327b8b

经过一段时间的发展，有一点是肯定的，你将永远后悔你做的代码。

我最后的遗憾之一来自于副作用，我习惯于向一些方法发送一些对象引用，并通过引用更新其内容，这在日常生活中很常见。

有了这样的代码，很容易把事情搞砸，并不断增加更多的责任，问题是你的代码变成了一匹野马，你永远不知道它要去哪里。就像这个“setPet”方法调用一样，它起初看起来是无害的，但是想象一下在一个有数千行代码的代码中，这个代码中的一个 bug 将是难以发现的。

在这段代码中我们可以注意到的另一件事是方法签名，这是一个谎言！我们怎么知道他要从某个服务中获取数据呢？而且就算我们把名字里的每一个小副作用都写进签名里，一瞥也要超过 200 个字符。

但是我想从我的方法中提取出这种逻辑，这样他的可读性更好！

我相信这一点，从我的代码中提取方法，通过漫长的副作用之旅发送我的类的引用，只是为了满足我对干净代码的理想，就像下面的代码:

当您阅读唯一的公共方法“insert()”时，它看起来很容易理解，代码也很简单，但是这里有很多不可思议的地方。以“ populatePersonFamily() ”方法为例，它设置了对象的 civil state 属性，但它从未在任何地方声明过，想象一下，如果前端想要更改这个值，您将不得不调试整个过程，直到您发现这个小技巧！

我从中得到的另一个教训是:如果我永远不会重用它，为什么我要创建一个新的方法来隔离一些逻辑呢？别误会，我不是说用五百行开始一个方法！都是关于设计模式和职责的。

我的代码的问题仅仅是对责任的误解，如果它是一个前端规则，为什么要验证服务中的 Person 对象呢？为什么个人服务应该知道如何设置宠物对象和映射模型的值？所有这一切都是另一天的主题，但你得到了想法。

副作用就像学校里的假朋友，你认为他在帮助你，直到你需要他的帮助来解决一些问题。很难跟踪一些 bug，很难知道一个新特性对一些使用引用的方法的影响，更难重构这样工作的方法。