软件熵解析:起因、影响与补救措施


原文请访问Software Entropy Explained: Causes, Effects, and Remedies

这篇文章主要针对的读者是对什么是软件熵、对他们工作会产生哪些实际影响、以及哪些潜在的因素促进熵的增长感兴趣的软件开发人员和项目经理。

主要目的是构成对软件熵的意识,因为它是所有形式的软件开发的一个要素。因此,我们将会探索一种能够把软件熵赋予某个具体值的方法。唯有通过量化软件熵,并且通过连续的发布观察它的增长 ,我们才能真正明白它对我们当前目标和未来计划所带来的风险。

何为软件熵?

软件熵起名于现实世界中熵的主要特点:即对混沌的度量,要么保持不变,要么随时间增长。换种方式来说,软件熵是对关于修改软件系统而产生的内在不稳定性的度量。

不幸的是,软件熵未能得到它应有的重视。

毫无疑问,从开发团队中随便拉个人过来,贸然地进行开发迭代,或者进行“快速修复” —— 这时,实际上,极可能助长了软件熵的增长。

软件开发是一门艺术,也是一种交易,因为它的核心构建块往往是欠缺考虑的。建筑工人工作用的是水泥和钉子,然而软件开发人员要面对是逻辑断言和一系列的假设。这些既不能握在手上进行测量,也不能精确地挪动0.125英寸(译者注:相当于3.3毫米)。尽管非正式的观察者可能会倾向于把软件开发和构建进行比较,但除了一些表面相似之外,这样做适得其反。

尽管困难重重,我们还是能够得出一些指导方针来帮助我们理解软件熵的来源、评估它对使目标遭受风险的程度,以及(如果需要的话)可以采取何种措施限制其增长。

The proposed definition of software entropy is as follows:
对软件熵的定义推荐如下:

E = I´C / S  

上面的I´是根据最后一次开发迭代中所引入的非期望的问题数量推断而来,C则是当前对系统的修改会导致一个新的I´ > 0的感观可能性,而S是下一次开发迭代的范围。通常而言,E的值在0.1以下认为是良好。如果E的值是0.5则认为是高,而大于1.0则认为是过载。

开发迭代的概念是我们对理解件熵的一部分。有一系列的活动周期,导致了系统中的这个行为变成了那个行为。在软件迭代期间,我们为自己设定的目标称为规模。在软件开发中,这样的周期包括修改或者扩展软件底层代码。

对代码的修改全部发生在开发迭代,虽然完成开发的人并不这样认为。这就是为什么那些以通过“快速但糟糕”方法论——缺少或少量需求收集与分析,构建系统为自豪的小型组织,依然使用开发迭代来实现他们的目标。他们根本没有进行任何计划。类似地,如果修改系统的行为偏离了我们的意图,它仍然通过开发迭代的方式来实现。

实际上,发生这些的风险正是在于我们对软件熵的意识用于解析何物以及希望用它的评估来限制什么。具体而言,可以这样定义软件熵。

任何给定的系统,都有一系列有限、已知、开启的问题I0。在下一次开发迭代结束后,将会有一系列有限、已知、开启的问题I1。系统内在的熵是指实际值偏离对I1的期望的可能性有多高,以及在随后迭代里此可能性会增长多少。

软件熵的影响

对于软件熵的影响的实践性经验,取决于我们如何与当前系统交互。

用户对软件持有静态的视图;他们只关心现在它如何动作而不关心系统的内部构件。通过执行一个预定义的动作,用户会假设软件以符合预定义的作为作出响应。然而,这些用户极少会推断当前正在使用的系统的熵级别。

软件熵与改变这一概念绑定,对于静态系统是没有意义的。如果没有修改系统的打算,它的熵也就无从说起。别一方面,一个尚未存在的系统(即,下一次迭代实际上是它的首次亮相)也是没有熵的。

  • 软件开发者对软件有一个流动的视图。他们关注系统当前是如何工作的,皆因它必须做出改变,并且他们关注系统工作的细节以便能设计出合适的策略。

  • 管理者可能拥有最复杂的软件视图,包括静态的和流动的。他们必须平衡短期内的迫切需要和未来商业计划进一步扩展的需要。

同时拥有这两种角色的人怀有期望。这些期望一旦破灭,软件熵就会现身。因此,软件开发者和管理者尽他们最大努力控制风险并作为计划,但是——除了外部混乱——尽管如此,仅当他们的期望落空时,我们才能来谈软件熵。 It is the invisible hand that breaks component interactions that weren’t in scope, causes production servers to inexplicably crash, and withholds a timely and cost-effective hotfix.

dogstar

一位喜欢翻译的开发人员,艾翻译创始人之一。

广州