在软件开发中应用80:20规则

经理们不想比他们更努力地思考。 他们喜欢简单的经验法则 ，快速直接的解决问题的方法，并指出正确的方向。 越简单越好。

最有用的经验法则之一是80:20规则 ：

80％的结果来自20％的原因，而80％的结果来自20％的努力。

这是收益递减的另一面：通过更聪明而不是更努力地工作，您可以从做更少的事情中得到更多，而不是从做更多的事情中得到更多。

您可以看到明显的情况，其中80:20规则适用于软件，而不会显得太费力。 例如，通过优化20％的代码可以发现80％的性能提高-尽管在性能优化方面，实际比例可能非常接近90:10甚至99：1。 但是，无论是80:20还是90:10或70:30，规则的工作原理基本相同。

80:20谁使用什么，您真正必须交付什么

软件中另一个著名的80:20规则是80％的用户仅使用20％的功能。 这是由Standish Group于2002年进行的研究得出的，他们发现：

• 从未使用过45％的功能；
• 19％很少使用；
• 有时为16％；
• 仅20％经常或始终使用。

就像变更成本曲线一样 ，这是基于有限证据的软件开发中广泛持有的“真相”的另一个示例-希望有更多的研究支持这一主张。

这一发现极大地影响了敏捷和精益开发，鼓励人们专注于提供最小的可销售功能或定义最小的可行产品 ，即使在大型企业项目中也是如此 。 与其尝试设计和规划系统可能需要的所有功能，不如想出一个最小，最严格的定义，即人们认为自己重要和有用的东西， 对功能进行优先级排序，并尽快交付 。

Standish Group的最新研究表明，思考小而交付量少是提高软件项目成功率的关键：尽管成功交付了70％以上的小项目，但大型项目“几乎没有成功的机会：…机会是两倍多的。迟到，超出预算且缺少关键功能”。

总而言之，毫无疑问，专注于为您带来80％的价值的20％的功能将最大程度地投资软件开发并提高整体用户满意度。 毕竟，没有足够的时间或金钱来做所有事情。 对于管理人员和利益相关者来说，自然的期望是全部想要并且现在想要全部。 因此，缩小范围而不使用100％的特征和功能不仅是一种有效策略，而且是一种谨慎的策略。”

但是，当人们玩耍过于安全而将门槛定得太低时，小脑子思考和更快地交付则也会带来不利影响：“价值降低和创新”。 提供20％或50％的系统并不总是足以成功，即使假设您可以弄清楚正确的20-50％是什么–即使对于某些人来说，其中某些“额外功能” 仍然很重要和必要，即使他们用的不多。 您将需要超过最低限度的可行产品来重新定义市场或人们的工作或娱乐方式， 从而使世界着火 。

80:20错误和测试

代码质量，错误和测试是80:20规则特别有用的另一个领域：

在20％的代码中发现了80％的错误

90％的停机时间来自10％（或更少）的缺陷

错误聚集在代码的某些部分 ，尤其是严重的错误。 您大多数最严重的问题将来自少数错误 。

“ Windows和Office中80％的错误和崩溃是由检测到的整个错误池中的20％引起的。”

微软的首席执行官：80-20规则适用于错误，而不仅仅是功能2002年10月

要了解大多数最严重的错误在哪里以及为什么会出现这些错误，以及需要采取哪些措施来阻止更多错误，您应该在这里花费很多时间。

一些研究发现， 您的代码中有一半可能根本没有任何错误 ，而大多数错误仅在10％到20％的代码中被发现 -通常是最经常更改的代码的10％到20％（请参见“ 80:20下面的代码将更改以及更改频率。

每次您在此代码中发现错误时，都有可能意味着还有更多错误需要查找和修复。 您发现的错误越多，呈螺旋式下降的可能性就越大。

Capers Jones说，必须处理（或解决） 易于出错的高风险代码，这是在系统生命周期内对开发人员生产力的最大最大拖累，并且不弄清楚是什么代码在给您带来最大的麻烦并做了某些事情这是开发团队可能犯的最昂贵的错误之一。

每当您触摸此代码时，即使您尝试对其进行修复，也有可能使它变得更糟，而不是变得更好：开发人员尝试修复其中的错误的可能性超过20％。容易出错的代码会无意中引入一个新的bug作为副作用。 浪费很多精力来试图理解和修复此代码，一遍又一遍地理解并修复它，这是浪费的：

“大多数容易出错的模块是如此复杂，难以理解，以至于一旦创建它们就无法修复”。

当代码变得如此糟糕时，它需要进行广泛且“ 残酷的重构 ”，以使其易于理解和使用，或者需要由知道自己正在做的事情从头开始编写的新代码“以外科方式删除并替换 ”。

如果您有一段时间在同一代码上工作的同一个人，则不难确定代码的哪些部分不好–询问团队中的任何人，他们都会知道该臭味来自何处。 在营业额大的大型系统和大型组织中，您可能需要随着时间的推移跟踪错误并为错误群集挖掘缺陷数据，而不是仅仅修复并继续前进。

80％的时间用于修正错误，其中20％的错误

有些错误比其他错误难修复。 有时是因为代码太糟糕了（请参阅上面的规则）。 有时是因为问题很难重现和调试 。 有时是因为它们比看起来的要深得多-设计中的基本错误， 无法编写代码的错误 。 为那些即使您最好的开发人员也无法告诉您什么时候（或什至是）某些错误将要修复的时期做好准备。

80:20更改哪些代码以及更改频率

通过查看代码库随时间的变化， Michael Feathers发现了更多的80:20幂律分布 （“ 从版本控制系统中发现令人震惊的事物 ”）：

80％的更改是在20％的代码中进行的

许多代码一次编写，并且从未更改：静态和标准化接口，基本接线和配置，后台功能。 然后还有其他代码始终在变化：80％的时间中有20％的功能被使用，并且需要根据需要的变化进行调整和调整，偶尔进行大修； 需要优化的核心代码； 和其他需要修复的代码，因为其中包含太多错误（再次返回上述80:20错误群集规则）。

Feathers发现，由于简单的内置偏差，随着时间的流逝，经常更改的代码也往往会变得更大。

向现有方法添加代码比添加新方法更容易，向现有类添加另一个方法比添加新类更容易。

结果，许多系统最终都有一些非常大的类，其中包含一些非常大的方法 ，并且随着代码的更改，它们会变得越来越大。

通过查看高流失区域的签入历史记录并通过对代码库进行简单的静态分析，可以轻松找到代码中的热点。 在这里，您可以从重构中获得最大的价值，在这里您可以尽最大的努力来防止代码丢失结构并变得危险地无法维护–这也是在进行更改（更改后）时自然应该最经常重构的代码更频繁=重构得更频繁（如果您正确重构 ）。

80:20和编程时间

前80％的代码在20％的时间内完成 …其余20％的代码在另外80％的时间内完成

通常不需要很长时间就能使某些东西几乎可以正常工作， 或者看起来像它可以正常工作 ，特别是如果您以迭代方式和增量方式工作，频繁且快速地交付。

但是，仍有很多工作需要在“幕后”完成，以完成工作，捕捉极端情况并处理错误，确保系统执行和扩展，查找并修复所有小错误，获取在部署代码之前，先将代码定型。 产品负责人/客户（和经理）通常不理解为什么花这么长时间才能完成工作的“最后20％”。 程序员经常忘记这也需要多长时间，并且不在估计中包括这项工作。 这就是为什么开发人员的估算经常错误的原因。 以及为什么在设定不切实际的期望时原型制作可能如此危险。

80:20和管理软件开发

牢记80:20的粗略规则可以使您专注于重要的事情，从而节省金钱和时间，并提高成功的机会：真正重要的功能，大多数最严重的bug所在的代码部分（以及花费最多时间修复的错误）； 代码中变化最大的部分； 以及您团队的工作方式和地点。

参考：在Building Real Software博客上，我们的JCG合作伙伴 Jim Bird 将80:20规则应用于软件开发 。

翻译自: https://www.javacodegeeks.com/2013/11/applying-the-8020-rule-in-software-development.html