强大的软件系统的四定律

墨菲定律 （“如果有什么不对的话，会的。”）于1949年在爱德华兹空军基地北基地诞生。 它以爱德华·A·墨菲上尉的名字命名，该上尉是空军项目MX981（该项目）的工程师，该项目旨在查看人在坠机事故中能承受多大的突然减速。 有一天，在发现传感器接线错误后，他诅咒负责的技术人员，并说：“如果有任何方法可以解决问题，他会找到。”

出于上述原因，最好进行一些质量保证流程。 我也可以称此博客为“稳定软件质量的四个定律”。 这是一些基本技术，可帮助您在更长的距离内获得卓越的质量。 如果您正在开发某些中心组件，如果该组件在生产中失败，则将导致严重损坏，这一点尤其重要。 好的，这是我的（永远不是最终的，不是整体的）实用质量保证提示列表。

法则一：促进变革

除了改变，没有什么是永久的。 如果不按照这个重要的重要事实来设计系统，则发生故障的可能性可能会高于平均水平。 促进变更的一种广泛使用的技术是开发足够的单元测试集 。 对系统进行更改后，通过单元测试可以发现现有功能的退化。 它还鼓励真正考虑正在开发的组件的所需功能和所需设计。

法则2：不要急于完成功能测试阶段

在经济学中，商品的边际效用是该商品消费增加（或减少）的收益（或损失）。 边际效用递减法则说，每个（同质）单位的边际效用随着单位供给的增加而降低（反之亦然）。 第一个功能测试用例通常会遍历涵盖所考虑软件主要路径的主要场景。 之前未执行过所有测试的代码。 这些测试用例的边际效用很高。 随后的测试用例可能会遍历相同的代码范围，例如在特定的验证条件下的特定旁路径。 这些测试用例可能覆盖应用程序中的三到四行代码。 结果，它们将比第一个测试用例具有更小的边际效用。

我关于功能测试的法则建议：只要执行下一个测试用例就产生了重要的效用，则适用以下条件：您在测试上投入的时间越长，结果越好！ 因此，不要匆忙完成功能测试阶段，而错过一些有用的测试用例（这是假设可以量化有用性的特殊情况）。 尝试找到有用的测试用例，这些用例有望在可感知的质量上有显着的提高。 另一方面，如果您使用负边际效用执行测试用例，则实际上您在投入更多的精力，那么您在感知质量上会有所收获。 在这种特殊（但不罕见）的情况下，客户端不会在系统的基础上运行功能测试。 然后，该定律将建议：应用程序在测试环境中的时间越长，结果越好。

法则3：运行（非功能性）基准测试

良好的永久软件质量的另一个保障是定期的负载测试 。 为了使结果可用，负载测试需要定义的稳定环境和测量值的基准（基准）。 这些值至少是：CPU，响应时间，内存占用量。 新版本的负载测试可以与旧版本的负载测试进行比较。 这样，我们还可以绕开经常陈述的要求，即负载测试环境需要具有与生产环境相同的容量参数。 在许多情况下，有可能看到并行用户相对较少（例如50个用户）的真正大问题。

如果单个用户概要分析结果不好，则进行负载测试的意义不大 。 因此，在每个版本中执行可重复的性能分析测试用例是一个好主意。 这样，可以将分析结果相互比较（再次：基准测试想法）。 我们进行CPU和经过的时间分析以及内存分析。 分析是与实际开发并行进行的活动。 明智的做法是关注生产中经常使用的主要方案。

法则4：避免依赖锁定

麻烦和严重危机之间的区别是解决引起麻烦的问题所花费的时间。 出于这个原因，您可能始终需要返回到先前版本的方法，并且需要一个后备方案来避免对业务造成严重影响的生产危机。 您可以通过避免依赖项锁定来启用回滚。 您的应用程序的运行时相关性可能在开发过程中通过联合接口或合同变更而存在于相邻系统中。 如果实施的要求导致接口和合同的更改，那么就不能简单地回滚，这是显而易见的。 因此，您需要避免过多的界面和合同更改。 较小的发行周期有助于减少一个发行版中应用程序版本之间的依赖性，因为将更少的更改投入生产。 反对依赖项锁定的另一种对策是让相邻系统在一个版本上兼容。

就强大的系统而言就是这样。

参考：来自JCG合作伙伴 Niklas的“关于IT体系结构的5'：健壮的软件系统的四个定律”。

翻译自: https://www.javacodegeeks.com/2012/06/four-laws-of-robust-software-systems.html