本文的目标读者是对软件工程中熵的定义感到好奇的软件开发人员或项目经理, , 这对他们工作的实际影响, 以及促成其增长的潜在因素.

主要目标是创建一个 软件熵意识 因为它是所有形式的软件开发中的一个因素. 此外，我们探索了一种方法，通过它可以赋予软件熵一个具体的值. 只有通过量化软件熵并观察其在连续发布中的增长，我们才能真正理解它对我们当前目标和未来计划构成的风险.

什么是软件熵?

软件熵 它的名字来源于现实世界中熵的主要特征: 它是一种混乱的度量，要么保持不变，要么随着时间的推移而增加. 换一种说法, 它是一种测量软件系统内在不稳定性的方法. 熵在计算机科学中有几种情况, 但是，我们将在本文中探讨的软件熵的类型对开发团队具有非常实际的含义，并且很少得到应有的重视.

当从开发团队中抽调人员时，软件中的熵是不被考虑的, 过早地开始开发周期, 或者实施“快速修复”——当, 事实上, 它最有可能增长.

软件开发 一门艺术和一种行业的核心构成要素是否定义不清. 而建筑工人用水泥和钉子工作, 软件开发人员使用逻辑断言和一组假设. 这些东西不能拿在手里检查，也不能按八分之一英寸来排序. 尽管不经意的观察者可能会试图将软件开发与构建进行比较, 除了一些表面上的相似之处之外，这样做会适得其反.

尽管困难重重, 尽管如此，我们还是可以列出一些指导方针，使我们能够理解软件熵的来源, 衡量它对我们的目标构成的风险的程度, 以及(如有必要)可以采取哪些措施来限制其增长.

本文提出软件熵的定义如下:

在哪里 I´ 是从上次开发迭代中引入的意外问题的数量派生出来的, C是感知到的对系统实施更改现在导致新系统的可能性 I´ > 0, S是下一个开发迭代的范围. 一般来说，E值小于0.1被认为是好的. E (0).5被认为是高的，值大于1.0势不可挡.

a的概念 开发迭代 是我们对软件熵理解的一部分吗. 这些是从系统的一种行为到另一种行为的活动循环. 我们在软件迭代期间为自己设定的目标称为its 范围. 在软件开发中，这样的周期包括修改或扩展软件的底层代码.

所有对代码的修改都发生在开发迭代中，即使执行这些修改的人并不这样认为. 这是, 较小的组织以使用“快速而肮脏”的方法构建他们的系统而自豪——很少或没有收集需求或分析——仍然使用开发迭代来实现他们的目标. 他们只是没有计划. 类似的, 即使修改后的系统的行为在某些方面偏离了我们的意图, 它仍然是通过开发迭代的方式实现的.

事实上, 这种情况发生的风险正是我们对软件熵的认识所要解释的，也是我们测量它的愿望所要限制的. 实际上，我们可以这样定义软件熵.

任何给定的系统都有一组有限的已知的、开放的问题₀. 在下一个开发迭代结束时，将会有一组有限的已知的、开放的问题₁. 系统的固有熵决定了我们对I的期望₁ 可能与其实际值不同，并且在随后的迭代中，差异可能会增加多少.

软件熵的影响

我们对软件熵影响的实际经验取决于我们如何与有问题的系统交互.

Users have a static view of software; they are concerned with 如何 it behaves now and do 不 care about a system’s internals. 通过执行预定义的操作, 用户假设软件将以相应的预定义行为响应. 然而, 用户最不善于推断他们正在使用的软件的熵值水平.

软件熵与变化的概念联系在一起，在静态系统中没有意义. 如果没有改变系统的意图，我们就不能谈论它的熵. 同样，一个尚不存在的制度(如.e.(下一次迭代实际上是它的第一次存在)没有熵.

从用户的角度来看，软件可能被认为是“有缺陷的”, 但是，如果在随后的迭代中，软件开发人员和管理人员按计划实现了他们的目标, 我们必须得出结论，系统中的熵实际上是相当低的! 因此，用户的体验告诉我们关于软件熵的信息非常少，如果有的话:

• 软件开发人员对软件有一种流动的看法. 他们只关心一个系统在必须改变时如何运作, 他们关心的是如何制定适当策略的细节.

• 管理人员对软件的看法可能是最复杂的，既有静态的，也有流动的. 他们必须在短期的紧急情况和延伸到未来的商业计划的需求之间取得平衡.

这两种角色的人都有期望. 每当这些期望被破坏时，软件熵就会显现出来. 这是, 软件开发人员和管理人员尽其所能地评估风险并为其制定计划, 但是——排除外部干扰——如果他们的期望仍然令人失望, 只有这样，我们才能谈论软件熵. 正是这只看不见的手破坏了不在作用域中的组件交互, 导致生产服务器莫名其妙地崩溃, 并保留了一个及时和具有成本效益的修复程序.

许多具有高熵水平的系统依赖于特定的个体, 特别是如果开发团队中有初级成员. 这个人拥有知识，没有他的“宝贵”投入，其他人就无法完成任务. 它不能在标准UML图或技术规范中捕获，因为它由异常的混合物组成, 预感, 和技巧. 这种知识并不依赖于逻辑上一致的框架，因此很难(如果不是不可能的话)转移给其他人.

让我们以极大的决心和努力来假设, 这样的组织能够自我扭转并稳定其IT部门. 情况似乎有所改善，因为, 当软件开发停滞不前时, 任何进展都是令人鼓舞的. 然而, 在现实中, 与在熵仍然很低的情况下触手可及的崇高目标相比，满足的期望很低，成就也很无趣.

当软件熵压倒一个项目时，项目就会冻结.

不能再有更多的开发迭代. 幸运的是，这种情况不会立即出现. 缓慢而险峻地走向悬崖边缘是每个系统都要经历的. 不管第一个版本组织得有多好，效率有多高, 在连续的开发迭代过程中，它的熵——以及意外出错的风险——将会增长，除非采取具体的步骤来防止它.

软件熵不能减少. 就像现实世界中的熵一样，它只会增长或保持不变. 起初，它的影响可以忽略不计. 当它们开始显现时，症状是轻微的，可以被掩盖或忽略. 但是，如果一个组织只是在软件熵成为项目中的主要风险时才尝试对抗它, 它将悲哀地发现，它的努力是徒劳的. 因此，当软件熵的程度较低且不利影响最小时，对软件熵的认识是最有用的.

这并不意味着每个组织都应该投入资源来限制其产品中熵的增长. 目前正在开发的许多软件——尤其是面向消费者的软件——预期寿命相对较短, 也许几年之后. 在这种情况下, 它的涉众不需要考虑软件熵的影响, 因为在整个系统被抛弃之前，它很少会成为一个严重的障碍. 然而，还有一些不那么明显的理由来考虑软件熵的影响.

想想运行互联网路由基础设施或将资金从一个银行账户转移到另一个银行账户的软件. 在任何给定时间, 该软件在生产中有一个或多个版本, 它们的集体行为可以以相当高的准确性记录下来.

的 风险承受能力 系统的度量是我们可以从一个开发迭代到下一个开发迭代轻松地允许多少和什么类型的意外行为. 对于刚才提到的系统类型, 风险承受能力远低于, 说, 路由电话的软件. 这个软件, 反过来, 与许多商业网站的购物车驱动软件相比，风险承受能力较低.

风险容忍度和软件熵是相关的，因为软件熵必须是最小的，以确保在下一个开发迭代中我们将保持在系统的风险容忍度之内.

软件熵的来源

软件熵来源于 缺乏知识. 它源于我们的公共假设与现有系统的实际行为之间的分歧. This fact explains why software entropy only has meaning in the context of modifying an existing system; it is the only time our lack of understanding will have any practical effect. 软件熵在一个系统中找到了最肥沃的土壤，这个系统的细节不能由一个人理解，而是在一个开发团队中传播. 时间也是知识的强力擦除器.

代码是一系列逻辑断言的表达式. 当软件的行为(因此它的代码)不符合它想要表达的逻辑时, 我们可以说它的固有代码熵. 这种情况可能以三种方式出现:逻辑是众所周知的，并且与其表达相背离, 对于代码要表达的逻辑有多种理解, 或者逻辑不是很清楚.

• 第一种情况——这种逻辑是众所周知的 与现在的表述不同——是最容易解决的，但也是最不常见的. 只有两个参与者维护的非常小的系统, 开发人员和负责商业计划的人, 会属于这一类吗.

• 第二种情况这种逻辑并不为人所熟知是罕见的. 出于所有的意图和目的，开发迭代甚至不能开始. 如果在某一点上所有利益相关者都同意，那么他们就可能面临第一种情况.

人类的头脑解释它的经验, 有效地过滤和修改它们，试图将它们融入个人框架. 在缺乏以自由交流思想为基础的有效发展习惯的情况下, 相互尊重, 明确的期望——对于系统当前如何工作的解释可能和团队成员一样多. 团队对于当前开发迭代的目标本身可能存在争议.

许多开发人员通过加强他们对自己需要什么以及系统“应该”如何组织的独特理解来保护自己免受这种情况的影响. 管理人员和其他利益相关者, 另一方面, 可能无意中试图改变其他团队成员的假设，试图让自己的生活更轻松.

现在我们来到了软件熵最常见的来源: 对于系统想要表达的逻辑，有多种不完整的解释. 因为这种逻辑只有一种表现形式, 这种情况显然是有问题的.

这种知识的缺乏是如何产生的? 无能是一种方式. 正如我们已经看到的, 对下一个开发迭代的目标缺乏共识是另一个原因. 但还有其他因素需要考虑. 一个组织可能声称采用一种开发方法，但随后随意地放弃了它的一些或全部方面. 然后，软件开发人员的任务是完成模糊的任务，这些任务通常是可以解释的. 对其开发方法实施变更的组织特别容易受到这种现象的影响, 尽管他们绝不是唯一的. 管理层不知道或无法解决的个人冲突也可能导致期望和结果之间的危险分歧.

还有第二种更重要的方式让我们失去了关于产品的技术知识:转让. 即使对最熟练的作家来说，在纸上捕捉技术知识也是一项挑战. 原因是 什么 抄写和……同样重要 如何. 如果没有适当的纪律，技术作者可能会记录过多的信息. 或者，他们可能会做出假设，导致他们忽略了要点. 制作完成后, 技术文档必须一丝不苟地保持最新, 对于许多几乎一写完文档就失去跟踪的组织来说，这是一个困难的命题. 由于这些困难, 技术知识很少单独以文件形式传递，也会以结对或其他形式传递, 人与人之间的互动.

每当活跃的参与者离开开发团队时，软件熵就会突飞猛进. 他们带走了大量有价值的技术诀窍. 复制这种诀窍是不可能的，而接近它需要相当大的努力. 有足够的关注和资源, 然而, 可以保留足够的知识，使系统熵的增长最小化.

还有其他软件熵的来源，但这些相对较小. 例如, 软件腐烂是指系统因环境变化而意外受到影响的过程. 我们可以考虑它所依赖的第三方软件(比如库), 但是还有其他的, 软件腐烂的更隐蔽的原因, 通常是由于系统所基于的假设发生了变化. 例如, 如果系统在设计时对内存的可用性有一定的假设, 如果可用的内存减少，它可能会在意想不到的时刻开始故障.

如何计算熵:赋值给C, S和I

I是软件系统中未解决的行为问题的数量, 包括没有承诺的功能. 这是一个已知的数量，通常在系统中被跟踪 JIRA. I´的值直接来源于它. I´ 在最后的开发迭代中，除了新引入的和未预料到的行为问题导致的工作单元的数量之外，被放弃或未完成的“工作单元”的数量是多少. 因为 I´ 被算作多少个工作单位, 我们可以把它和S的值联系起来, 在相同的工作单元中，下一个开发迭代的范围是什么. “工作单元”究竟由什么组成取决于开发方法.

C是感知概率, 当范围内的工作单元被实现时, 在下一次迭代中实际开放问题的数量将比现在估计的要多. This value lives in the domain 0 <= C <= 1.

有人可能会说概率C正是软件熵所要测量的. 然而，这个值和我们对软件熵的度量有根本的不同. 的 感知到的 事情出错的概率就是:它不是一个真实的值. 然而, 它是有用的，因为参与项目的人的感受是了解项目稳定性的宝贵信息来源.

范围S考虑了拟议变化的幅度，必须用与I´相同的单位表示. S值越大，熵值就越小，因为我们增加了提议变化的范围. 尽管这听起来可能违反直觉, 我们必须记住，熵是衡量系统发展的尺度 不 满足我们的期望. 仅仅说熵是对引入问题的可能性的度量是不够的. 我们很自然地尝试和预测风险，并在我们的计划中考虑它们(因此在我们的估计中), 哪个可能会增加 ₀). 很明显, 我们就越有信心承担更大的变化范围, 系统中的熵就越少，除非那些计划改变和/或执行改变的人是不称职的. 然而，这种可能性很可能反映在当前的价值上 I´.

注意，我们不需要尝试指定I的实际值之间的差值的大小₁ 它的期望值. 如果我们在制定计划时假设我们的计划是正确的, it is 不 also reasonable to assume we can predict the degree to which the result will 不 满足我们的期望; we can only specify a 感知到的 chance C that it won’t. 然而，实际值I的程度₁ 与其期望值不同的重要输入是熵的计算，在下一次迭代中以派生值的形式出现 I´.

理论上，I´有可能是负值. In practice, 然而, this situation will never occur; we do 不 usually solve problems accidentally. 的负值 I´ 不是一个令人欣慰的迹象吗. 它们暗示着计算熵的方法是有缺陷的. 软件熵的增长可以, 当然, 采取具体措施减少, 如下所述. 然而，在这种情况下， I´ 不应该假设负值，因为我们总是把我们的期望纳入我们的设计.

C是主观值. 它存在于开发迭代参与者的头脑中，并且可以通过轮询他们并计算结果的平均值来推断. 这个问题应该以一种积极的方式提出. 例如: 从0到10分，10分最有可能, 您如何估计团队在这个开发迭代中实现所有目标的机会?”

注意，这个问题是关于整个团队的目标，而不是一个子集. 响应为10表示C的值为0, 而响应为7则表示值为 .3. 在较大的团队中, 每个回答可能会根据相关因素进行加权, 比如一个人在项目中投入了多长时间，他们实际花了多少时间在项目上. 然而，能力不应成为衡量答复权重的一个因素. 没过多久, 即使是团队中资历较浅的成员，也会对团队在实现目标方面的有效性有所了解. 足够大的团队可能希望在计算剩余的平均值之前丢弃最高和最低的报告值.

询问专业人士他们的团队失败的可能性有多大，是一个敏感而具有挑衅性的问题. 然而，这正是任何希望量化熵的组织都需要问的问题. 确保诚实的回答, 参与者应该匿名给出他们对C的估计，而不必担心受到影响, 即使他们报告的价值高得吓人.

S必须在相同的“工作单位”中赋值 I´ 因此高度依赖于开发方法. 对于使用一个方面的团队 敏捷方法，故事似乎是S和S最明显的“工作单元” I´. 在这种情况下, 开发迭代的范围跨越每个定期计划的发布到生产, 小调或大调都行. I´应该被量化为在发布之前的每个sprint中没有成功完成的故事数量的总和，以及在发布后出现意外问题时为包含在未来sprint中的故事数量的总和.

请注意，我们不认为热修复或其他未计划的产品版本定义了开发迭代的范围, 我们也不应该减去任何相关的故事 I´.

这种方法的困难在于，在将bug分解成故事之前，必须进行一段时间的发现和分析. 因此，I´的真实值只能在延迟之后定义. 此外，对C的轮询自然发生在每次冲刺开始时. 因此，得到的结果必须再一次在整个释放的时间跨度内求平均值. 尽管困难重重, 任何采用敏捷方法的团队都可能发现，故事是量化S的最准确的单位 I´).

现在还有其他的开发方法在使用. 无论采用何种方法, 测量软件熵的原则保持不变:软件熵应该在发布到生产之间进行测量, S和I应该用相同的“工作单位”来度量,对C的估计应该以一种无威胁的、最好是匿名的方式从直接参与者那里得到.

减少E .的增长

系统的知识一旦丢失，就再也无法恢复. 因此，软件熵不能减少. 我们所能做的就是抑制它的增长.

通过在软件开发过程中采取适当的措施，可以限制软件中熵的增长. 敏捷开发中的结对编程在这方面特别有用. 因为在编写代码时涉及多个开发人员, 重要细节的知识被分发，团队成员离职的影响被减轻.

另一个有用的实践是生成结构良好且易于使用的文档, 特别是在采用瀑布方法的组织中. 这样的文档必须以每个人都能理解的严格的、定义良好的原则为后盾. 依赖文档作为沟通和保护技术知识的主要手段的组织非常适合这种方法. 只有当有 no 关于如何编写和使用内部编写的文档的指导方针或培训——在使用RAD或敏捷方法的年轻组织中经常出现这种情况——它们的价值变得值得怀疑.

有两种方法可以减少系统中熵的增长:执行旨在减少熵的更改 I´ 或执行旨在减少C的更改.

第一种方法涉及重构. 旨在减少I´的操作本质上是技术性的，读者可能已经很熟悉了. 必须进行开发迭代. 迭代中旨在减少熵增长的部分 不会带来任何切实的商业利益 虽然它会消耗时间和资源. 这一事实往往使得减少熵的增长在任何组织中都是一种硬性推销.

减少C的值是一个更有效的策略，因为其效果是长期的. 此外，C对I´to S比值的增长起着重要的制约作用. 减少碳排放的行动往往集中在人类的行为和思维上. 尽管这些操作本身可能不需要开发迭代, 当参与者接受并适应新的过程时，它们将减缓后续的迭代. 就应该做出哪些改进达成一致这一看似简单的行为本身就是一条充满危险的道路, 当项目参与者和涉众的不同目标突然暴露出来时.

结束

软件熵是指改变现有软件将导致意外问题的风险, 未满足的目标, 或两个.

虽然在软件最初创建时可以忽略不计, 软件熵随着每次开发迭代而增长. 如果允许不加检查地进行下去, 软件熵最终将使进一步的开发停止.

然而，并不是每个项目都应该考虑到软件熵的影响. 在熵能产生明显的有害影响之前，许多系统就会停止生产. 对于那些寿命足够长的人来说，熵带来了可信的风险, 建立对它的意识并衡量它的程度, 虽然仍然很低, 提供一种方法来确保开发不会过早中断.

一旦一个系统完全被软件熵的影响所淹没, 不能再做任何改变，发展基本上已经结束.