JavaScript 里的奇葩知识

但我们的世界并没有停滞不前，消费者和企业对软件的期望一直在迅速增长。我们期望软件能比 20 年前做得更多。当我们开发出这些更大型、功能更丰富的应用程序时，为了保持它们的可靠性、功能性和可理解性，不得不改变软件的开发方式。

以下是我们在过去 20 年里看到的几个行业变化：

源码控制——源码控制一直都存在，但并不像现在这么普遍。不认为这增加了偶发复杂性？那就去问问第一次使用 Git 的初级工程师，他们是怎么想的。

自动化测试——我们引入了很多测试类型和测试工具。我们需要进行验收测试、集成测试、单元测试等等……这给项目带来了大量的偶发复杂性，但有助于确保交付的软件是高质量的，且功能是符合预期的。

拆分系统——随着系统复杂性的增加，组件之间连接和交互的量会呈二次级数增长。也就是说，在某种程度上，如果软件设计得不好，交互量将会继续增长，直到因为自身的复杂性而垮掉。拆分系统，特别是进行分布式拆分，会带来大量的意外复杂性。
 

2. 偶发复杂性

我们假设，这是一个颇具挑战性的数学问题，完全用人脑来解决是徒劳的，所以需要使用计算器。这就是偶发复杂性。还记得第一次使用图形计算器的情形吗？在这个时候，偶发复杂性就是学习如何在计算器上输入所有复杂的数学信息来帮你解决问题。你不一定要使用计算器，但你知道它对你有用，而且不会太难学。

现在，我们假设你对 Mathematica 很熟悉。Mathematica 是一个非常强大和复杂的软件，不过既然你已经知道它了，就决定用它来解决问题。你在学习 Mathematica 上投入了很多，所以不需要很多额外的努力，只是增加了解决方案的偶发复杂性。

几周后，你的一位同事遇到类似情况，他记得你曾经解决过一个类似问题。他们来找你，看你是如何解决问题的，然后你把 Mathematica 发给他们。你认为这个时候会发生什么？你认为他们会去学习数学吗？不，他们会想出另一种解决问题的方法，或者试图让你替他们解决问题。

正如你所看到的，这两种复杂性来自不同的地方，但它们之间有着紧密的联系。如果不引入一些偶发复杂性，就无法解决问题。即使是一支铅笔和一张纸也会带来一些微不足道的偶发复杂性。

如果没有偶发复杂性，就无法解决问题。

3. 它在软件领域是怎样体现的

这可能会让你感到惊讶，在过去 20 年中，软件领域本质复杂性与偶发复杂性比率在急剧下降。David Heinemeier Hansson（Ruby on Rails 之父）用“概念压缩（conceptual compression）”这个词来描述这种趋势以及它是如何让我们的行业变得更好的。在过去的 20 年中，开源框架和库的激增是减少软件系统偶发复杂性最强大的力量。

与 20 年前相比，解决业务问题所需的代码量已经减少了一个数量级，因此你可能会认为开发软件将比那时快一个数量级。但这种情况似乎并没有发生，为什么会这样？

软件变得越来越容易开发，但与此同时，其他现象也在发生：

• 我们对软件的要求越来越高
• 公司内部的软件数量呈爆炸式增长
• 采用新技术的步伐正在加快

4. 我们对软件的要求越来越多

尽管我们正在利用越来越多的外部工具和库来开发软件，让软件开发变得越来越容易，但我们对软件的要求也越来越高，仅这一点就抵消了大量的收益。如果我们用现代工具来开发 2000 年代的 Web 应用程序，会看到软件开发的生产力有十倍 (或更多) 的提升。

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!