开发区域

MATLAB高级软件开发

全球进全球出

在MathWorks的过去几年里,我们一直在从传统的过程测试框架过渡到现在的MATLAB原生单元测试框架。随着越来越多的团队开始看到并利用它的各种好处,看到这个框架的内部采用率稳步增长是非常棒的。

然而,在迁移到新的MATLAB单元测试范式的过程中,我们看到的最大挑战之一是存在与新框架不兼容的团队特定的帮助程序、工具和生态系统。

为什么它们不相容?

因为遗留框架的一个核心特性是全球可用的全局变量破坏设计信息.先读一读那篇文章,它不会太长。这些评论快结束时,我开始从椅子上跳起来,拳头在空中喊:是的!是的!——啊! !

继续读吧。我将等待…

准备好了吗?很棒的东西,是吗?这些听起来熟悉吗?如何:

“很多人说他们不想[没有全局参数的设计],因为他们想象他们最终会在代码中到处传递额外的参数。”

...或者

“当一个东西是全球性的,它在任何地方都可以使用,人们往往会不受约束地使用它。”

这就是使用全局状态的真正成本。为什么全局状态是一件坏事有很多很多的原因,但这可能是最普遍和最邪恶的:全局状态将整个生态系统的整个设计变成一个巨大的耦合乱码,难以改变的混乱。全局状态作为的隐式参数生态系统中的每一个函数和方法调用.当我们允许全局状态时,我们说,“随意使用这个,哦,顺便说一下,因为你经常需要它,我们会直接放弃你的要求,告诉我你需要使用它。”这有点像银行说,“你似乎经常从你的账户里取钱,我们就会继续,不需要你使用银行卡和密码。”无需在此背景下说明自己的身份,我们将假设无论何时从您的帐户中提取资金都是由您批准的。看看我们让你多轻松。你甚至都不用带钱包!”

会出什么问题呢?

谬论在于,全局状态一开始让事情看起来更容易,因为它不需要设计规则。我们只会意识到它所带来的问题,但到那时,设计上的破坏已经造成了。要撤销依赖于它的设计几乎是不可能的。引入全局状态的糟糕设计选择会对在其生态系统中运行的整个工具集的设计产生负面影响。

在MATLAB单元测试框架中,我们不依赖全局状态,而是要求那些在框架中操作的人具有适当的上下文来执行诸如验证和断言之类的事情。在不需要使用与遗留测试相同的生态系统的测试中,这不会导致任何重大问题。当生态系统是干净的,有许多模型方法和模式来编写测试和相关的测试工具。

然而,另一方面,当一个测试利用了完整的生态系统和围绕参数的全局可访问性构建的工具时,这是一个更困难的问题。

这不仅仅是一个测试问题,这是一个非常普遍的软件工程原理。向软件系统引入全局状态会导致并发性问题(例如,使用并行计算工具箱进行并行),极大地复杂化了可重入性,并且几乎总是用幽灵般的动作在远处

MATLAB中的全局状态是什么?显而易见的答案是使用全局变量.然而,下面是一个简短的列表,可以很容易地用于在MATLAB中引入全局状态:

  • 持续的变量
  • 对象与常数包含可变句柄对象的属性
  • 包含句柄对象的MATLAB类中的默认属性值
  • 全局对象(如根对象)上的Appdata
  • 单例设计模式,如果它允许访问任何可变状态
  • 在全局可访问(和可变)的基本工作空间中定义的变量

我发现很少(几乎从来没有)对给定问题的解决方案真正需要使用这种全局状态。如果你被诱惑了,要再三考虑你的设计(20次!)如果最后使用它,始终确保将此状态的暴露限制在尽可能少的客户机上。




发布与MATLAB®R2015b

|

评论

如欲留言,请点击在这里登录您的MathWorks帐户或创建一个新帐户。