沃斯定律并不是真正的定律。事实上，它们都不是法律。它们是格言：
这里还有另一个不是真实定律的定律：摩尔定律是观察到密集集成电路(IC)中的晶体管数量大约每两年翻一番。
这意味着我们可以期待计算机在降低成本的同时提高速度和容量。可悲的是，这就是沃斯定律的用武之地：
沃斯定律是一条关于计算机性能的格言，它指出软件变慢的速度比硬件变快的速度更快。
Https://en.wikipedia.org/wiki/Wirth%27s_law。
虽然摩尔定律自1975年以来已被证明是正确的，但沃斯定律似乎也是正确的。帕斯卡(Pascal)的设计师尼克劳斯·沃思(Niklaus Wirth)在1995年写了一篇文章：
大约25年前，交互式文本编辑器可以设计成只有8000字节的存储空间。(现代节目编辑的要价是这个数字的100倍！)。操作系统必须管理8000字节，编译器必须能够容纳32K字节，而它们的现代后代需要兆字节。所有这些膨胀的软件变得更快了吗？相反地。如果没有速度快一千倍的硬件，现代软件将完全无法使用。
尼克劳斯·沃斯(Niklaus Wirth)-为精益软件辩护
现代软件开发的问题是多方面的。沃斯指出了一个至关重要的方面：时间。
虽然这在1995年是正确的，但这不再是最重要的因素。我们现在必须处理一个更大的问题：抽象。开发人员从不从头开始构建东西，这从来不是问题，但现在他们也变得懒惰了。
Edsger W.Dijkstra试图提高代码质量，并创造了结构化编程的概念。他试图让编程走出危机状态，他得到了哈兰·D·米尔斯(Harlan D.Mills)、理查德·C·林格(Richard C.Linger)和伯纳德·I·威特(Bernard I.Witt)等程序员的支持。在很短的一段时间内，编程被视为真正的手艺。程序员关心他们程序的质量，包括清晰度和效率。
那些时代已经过去了。1995年，随着Java、Ruby、PHP和Javascript等高级语言的引入，也就是Wirth撰写文章的同一年，编程变得更加抽象。
像这样的语言使编程变得容易得多，并使许多事情不再是程序员所能做的。它们是面向对象的，并且附带了IDE和垃圾回收功能。
这意味着程序员需要担心的事情更少了，这当然很棒。可悲的是，任何事情都是有代价的。担心的事情少了，也意味着思考的事情少了。1995年是程序员不再考虑程序质量的一年。
这也标志着图书馆广泛使用的开始，这可能是更大的问题之一。别误会，我喜欢图书馆。这是我能把事情做好的唯一原因。然而，图书馆永远不会提供你所需要的东西。
因为库不是为一个特定的项目创建的，所以它的功能可能比您真正需要的要多一点。你会说，没问题。然而，事情堆积得相当快。即使是喜欢图书馆的人，也不想重新发明轮子。这导致了我们所说的依赖地狱。尼古拉·杜扎(Nikola Duza)用Javascript写了一篇关于这个问题的帖子。
问题看起来不是那么大，但试着抓住这里正在发生的事情。在尼古拉写的另一个教程中，他列出了一个简单的待办事项清单。它可以在您的浏览器中使用HTML和Javascript。他使用了多少个依赖项？13,000个。
这些数字是疯狂的，但这个问题只会继续增加。随着新的、非常有用的库不断构建，每个项目的依赖项数量也将不断增长。
这意味着尼克劳斯在1995年警告我们的问题只会随着时间的推移而变得更大。
而且，您不必学习汇编，也不必开始在其中编写Web应用程序。一个不错的开始方式是拆分库。不要创建一个大型库来完成您可能需要的所有功能，只需创建多个库即可。您的神一样的库仍然可以存在，但仅仅是作为一个包装器。
这样，程序员只需选择他真正需要的库，而忽略他不会在应用程序中使用的功能。不仅他的依赖项更小，而且它们使用的依赖项也更少，因为不需要安装未使用的功能的依赖项。
注：建议的解决方案显然不是解决方案。例如，它需要一种很好的软件版本化方法来避免新的依赖地狱。