为什么开发人员从不使用状态机

最新推荐文章于 2022-04-11 08:12:26 发布

danpu0978

最新推荐文章于 2022-04-11 08:12:26 发布

阅读量338

点赞数

文章标签： java python 大数据数据库 javascript ViewUI

本文探讨了开发人员通常不使用状态机的原因，指出当对象状态较少时，手动管理状态可能更简单。然而，随着状态数量增加，状态机的价值显现，提供了一致性、易于扩展和审计跟踪等功能。通过引入状态机，代码得以简化，库质量得到提升。

摘要由CSDN通过智能技术生成

几个月前，我在Shopify博客上看到了一篇关于状态机的小博客文章。信息是状态机很棒，开发人员应该更多地使用它们-考虑到我最近在CrowdHired使用状态机的经验，我当然可以同意。但是，这让我开始思考，在开发人员的职业生涯中，我实际上使用过多少次状态机（ 或者是单独的库，甚至是手动滚动的抽象机 ）？答案是零次–这让我感到非常惊讶，因为状态机确实非常有用。因此，我决定进行一些自省，并弄清楚为什么我们倾向于以即席方式管理“ 状态 ”和“ 状态 ”字段，而不是按照明确要求的方式进行管理。

直到我们需要时，我们才需要一个

问题在于您几乎永远不会创建一个完全具有其所需的所有行为的对象 ，而是随着时间的推移逐步建立它。对于状态机候选对象可以处于的“ 状态 ”也是如此。因此，一开始，您不会觉得对象的状态机行为足够复杂以至于无法保证“ 成熟的 ”状态机（ YAGNI以及所有爵士乐 ），但是后来-当它足够复杂时-您会觉得您投入了太多的时间/精力来替换具有相同功能的产品。有点赶不上22了。 这太过分了，到时候还没到，为时已晚 。

状态机是蓬松的兔子（ 不是特别威胁 ）

我们中那些攻读计算机科学学位的人会记住我们计算理论学科中的状态机，而记忆通常不是人们喜欢的。有复杂的图表和数学符号，确定性和非确定性， Moore和Mealy以及缩写galore（ DFA，NFA，GNFA等 ）。我们开始相信状态机比实际状态复杂得多，因此，实用主义使我们认为“ 成熟的 ”状态机过大。

但是，您日常开发中可能需要的大多数状态机与它们的计算理论对应物没有什么共同之处 （ 除了…errr…理论 ）。您拥有的状态是字符串，而事件是导致从一种状态转换为另一种状态的方法– state_machine （ 至少对于Ruby中的state_machine gem而言 ）。关键是，即使您有两个状态，状态机也不过分，只要有一个好的库可以依靠，就可以采用临时解决方案。

即使是好工具也不是好工具

我可能会猜测，大多数语言都可以使用不错的状态机库（ 前面state_machine的Ruby的state_machine只是一个示例 ）。但是，即使是蓬松的兔子也有学习曲线（ 我在这里将隐喻延伸到了突破点之外 ）。如果您正在解决问题，那将不是一个问题，但是您可能要做的就是替换现有的解决方案。由于事实发生后我们倾向于转向状态机库（ 我们的临时解决方案现在正在工作 ）。就像所有具有“ 潜在的未来利益 ”的事物一样，即时价值也很难为自己辩解 （ 除非您以前有过使用经验 ）。轻微的学习曲线只会使规模进一步向“ 没有它我们可以生存 ”的方向发展。如果您从没有机会，那么工具的好坏并不重要。

真的很难理解（ 直到您读完它 ）–如果您确实给一个好的状态机库一个机会，生活会好得多。当我们最终在CrowdHired “ 咬住了子弹 ”并重新调整了我们的一些核心对象以使用state_machine gem时，区别立即显而易见。

首先，学习曲线很小，我确实花了几个小时来阅读源代码和文档，但是在那之后，我有了一个好主意，可以做什么和不能做什么（ 我可能会深入研究state_machine gem在某个时候 ）。
集成本身几乎可以轻松完成，但是将所有代码移动到与新状态机内联的位置是一个很大的麻烦。事后看来， 当我们的物体只有几个状态时，我们便做到了，这简直是轻而易举 。
现在，我们可以轻松地引入更多状态，从而为我们的用户提供更多信息，并允许我们跟踪事物的细节。在它成为YAGNI造成痛苦之前，现在我们发现我们“绝对需要 ”，因为这是如此容易。
现在，我们从状态转换返回的值是100％一致的（ true/false ）。在返回对象之前，对象的数组为nil，true / false，具体取决于谁编写它以及何时编写。
现在，我们只需将state_machine-audit_trail （ 请参见Shopify post ）放进去，就可以保持对状态转换的审计跟踪，而之前很难将它挂接到任何地方，所以我们一无所有。
我们删除了一堆代码并改善了代码库–就我而言，这始终是值得实现的目标。

我的直觉是，大多数阅读Shopify帖子的人在精神上都同意这一点，但对此却一无所知（ 这与我的 相处 有点像 ）。 由于对状态机的复杂性和/或无法量化收益的误解，我们似乎避开了状态机。 但是，只要您不尝试在事件发生后不对状态机进行改造，那么其复杂性就比您想像的要少，收益也比您预期的要多。因此，下次您有了一个甚至暗示有“ status ”字段的对象时，只要在其中插入一台状态机，您就会很高兴。我保证或您的退款:)。

参考： 为什么开发人员从不使用 Skorks博客博客上JCG合作伙伴 Alan Skorkin的状态机。